Álvaro José Agámez Licha
Senior Software Developer
Ingeniero en Informática con más de 18 años de experiencia en el desarrollo de software enfocado en la web, he trabajado en diferentes roles como Fullstack, Frontend, Backend y Tech Lead.
Siempre me encantó JavaScript, y cuando conocí Node.js alrededor del año 2011 no dudé en adoptarlo de inmediato en la medida que los proyectos en que trabajaba me lo permitían.
Para mi el Desarrollo de Software es una pasión y desde siempre tuve claro que esta era la única área a la que me quería dedicar dentro del mundo de la tecnología; además siempre me he preocupado por la calidad del software, patrones de diseño, arquitectura y buenas prácticas.
Desde hace 1 año resido en Suecia y me desempeño como Senior Software Engineer.
Clean Architecture es la guía de arquitectura de sistemas propuesta por Robert C. Martin (Tío Bob) derivada de muchas guías arquitectónicas como la Arquitectura Hexagonal, la Onion Architecture, etc... a lo largo de los años.
El diseño y arquitectura del software generalmente se refieren a la base, estructura y organización de la solución. Al diseñar una solución sostenible, siempre debemos considerar la mantenibilidad. Mantenibilidad significa que la solución debe estar bien diseñada con una base sólida. La solución debe seguir los mejores principios y prácticas de diseño.
La arquitectura limpia, también conocida como Domain-Driven Design, ha evolucionado con mejoras considerables en los últimos años. A continuación se dan algunos nombres de arquitectura utilizados para la arquitectura limpia a lo largo de los años.
Algunos nombres de arquitectura utilizados para la Clean Architecture a través de los años:
Domain-Driven Design (DDD) es el enfoque para el desarrollo de software que nos permite traducir dominios de problemas complejos en software rico, expresivo y fácil de evolucionar. Es la forma en que diseñamos aplicaciones cuando las necesidades de nuestros usuarios son complejas.
Inicialmente presentado y popularizado por el programador Eric Evans en su libro de 2004, Domain-Driven Design: Tackling Complexity in the Heart of Software. Su objetivo es facilitar la creación de aplicaciones complejas al conectar las piezas relacionadas del software en un modelo en constante evolución.
DDD se enfoca en tres principios básicos:
Entidad: Un objeto que se identifica por su hilo consistente de continuidad, a diferencia de los objetos tradicionales que se definen por sus atributos.
Servicio: Esencialmente, un servicio es una operación o forma de lógica comercial que no encaja naturalmente dentro del ámbito de los objetos.
Factory: Queremos crear objetos de dominio de muchas maneras diferentes. Asignamos objetos de dominio mediante una factory que SQL directamente, JSON o Active Record que se devuelve desde un ORM.
Hay otros bloques u objectos dentro de DDD, pero creo que estos son los más importantes que en mi experiencia con Node.js nos permiten desarrollar nuestras aplicaciones de una manera apropiada siguiendo DDD.
En general, DDD introduce tres capas:
Infraestructura: maneja la persistencia de DB, caché, servicios externos, etc.
Dominio: Maneja la lógica de negocio. Aquí, la lógica de negocio se refiere a algunas operaciones complejas (por ejemplo, transferencia de dinero), no operaciones CRUD.
Aplicación: Maneja la orquestación de las capas de dominio, como el servicio de aplicación. Por ejemplo, llame a user.register(userInput); event.dispatch(userRegisterEvent).
Node.js no es Java, no es C#, no es [pongan aquí un nombre], así que muchos patrones de diseño o arquitecturas no se pueden o deben implementar exactamente como la literatura nos sugiere, aquí es donde nuestra experiencia marca la diferencia entre un buen proyecto y el infierno.