01 - Arquitecturas de software

Podemos clasificar una aplicación atendiendo a distintos criterios. Estas decisiones se combinan: por ejemplo, una aplicación puede desplegarse como monolito modular y organizarse internamente por capas con inversión de dependencias.

Las arquitecturas limpias protegen las reglas de negocio frente a los detalles técnicos y externos.

• Independencia de frameworks: el framework es una herramienta, no el centro de la aplicación.
• Testeable: las reglas de negocio pueden probarse sin levantar la interfaz, la base de datos ni el framework.
• Independencia de la interfaz de usuario: la misma lógica puede exponerse mediante interfaces distintas.
• Independencia de la base de datos: se puede sustituir la tecnología de persistencia sin reescribir las reglas de negocio.
• Independencia de agentes externos: las reglas de negocio no dependen de servicios externos concretos.
• Regla de dependencia: las dependencias del código apuntan hacia las políticas y reglas de negocio, no hacia los detalles.
• Inversión de dependencias (DIP): las abstracciones que necesita el núcleo pertenecen al núcleo; los detalles externos las implementan.

Organiza el código según responsabilidades. En aplicaciones web es habitual distinguir estas capas:

En una arquitectura por capas tradicional, controller llama a domain y este utiliza persistence. Si el dominio depende directamente de clases concretas de persistencia, queda acoplado a la tecnología.

Cuando domain define las interfaces que necesita y persistence las implementa, se invierte la dependencia respecto a la persistencia y se aplican principios de arquitectura limpia.

Separa el núcleo de la aplicación de los sistemas externos mediante puertos y adaptadores.

• Puerto: abstracción que describe cómo se usa el núcleo o qué necesita del exterior. Por ejemplo, una interfaz de repositorio.
• Adaptador: conecta un puerto con una tecnología concreta. Por ejemplo, un controller REST o una implementación JPA.
• Dirección de dependencia: el adaptador implementa o invoca el puerto; el dominio no conoce el adaptador.

Describe cómo se empaqueta, ejecuta y despliega la aplicación. Es un criterio distinto de la organización interna.

• Monolito no significa necesariamente código desordenado: puede tener módulos bien diseñados. Es una opción adecuada para aplicaciones pequeñas y poco complejas, como un CRUD sencillo.
• Monolito modular: los módulos colaboran dentro de un mismo proceso mediante APIs explícitas. Las fronteras limitan dependencias y acceso a datos internos.
• Microservicio: servicio autónomo que se despliega por separado y es responsable de sus datos. No basta con separar una aplicación en varios proyectos.

La comunicación entre componentes puede ser síncrona o asíncrona. La forma concreta depende de si los componentes están dentro del mismo proceso o son servicios distribuidos.

• Los módulos de una misma aplicación pueden comunicarse de forma síncrona, mediante llamadas directas a las APIs públicas de otros módulos.
• También pueden comunicarse de forma asíncrona, publicando eventos que otros módulos consumen.
• Los eventos internos no implican comunicación de red ni crean por sí solos aislamiento o una transacción independiente.

• Los microservicios se comunican a través de la red.
• La comunicación síncrona suele realizarse mediante peticiones HTTP y respuestas.
• La comunicación asíncrona se realiza publicando mensajes o eventos en un intermediario (broker), como RabbitMQ o Kafka; los consumidores los procesan posteriormente.
• En cualquiera de los estilos distribuidos, hay que contemplar fallos de red. Con mensajería, los consumidores deben ser idempotentes para tolerar entregas duplicadas.