Cuando se aborda un nuevo proyecto de software en el que intervienen múltiples stakeholders, se implican diversos componentes o sistemas terceros, o trata de implementar grandes flujos de negocio, es decir, un proyecto con un alto nivel de complejidad, se afronta el mismo problema de siempre: ¿Qué estrategia de diseño tomar? ¿Qué lenguaje de negocio utilizar? ¿Qué patrones de arquitectura tecnológica aplicar?
Las respuestas a estas preguntas deben basarse siempre en el análisis de aspectos tales como la mantenibilidad que se requiere, el nivel de integración, la escalabilidad o simple y llanamente el coste de implementación. No obstante, entre estos aspectos suele olvidarse uno clave: el lenguaje, que no es otra cosa que el mecanismo o punto de unión que debe permitir la conexión entre el mundo del negocio empresarial a digitalizar y el producto digital final. En otras palabras, el aspecto que marcará el éxito.
¿En qué punto entra en juego el concepto de arquitecturas limpias y DDD (Domain-Driven Design)? ¿En qué ayuda a trabajar y optimizar ese aspecto clave? Para empezar, en este artículo se abordarán conceptos básicos de arquitectura.
Arquitecturas limpias y el hexágono mágico
La arquitectura hexagonal se basa en los siguientes principios y objetivos fundamentales:
- Separar de forma explícita y contundente las capas de usuario, negocio y servidor.
- Derivar y empujar las dependencias desde las capas de usuario y servidor hacia la lógica de negocio.
- Aislar e independizar al máximo cada una de las capas, suprimiendo acoplamientos indebidos y dotando a cada componente de una responsabilidad muy específica.
Desde un punto de vista práctico, este principio de arquitectura se basa en una idea tan antigua como eficaz: divide y vencerás. Separar o partir el problema en trozos independientes facilitará no sólo la comprensión del problema global, sino que hara más sencilla la implementación de la solución y su posterior mantenimiento. Por otro lado, prepara el terreno para alcanzar una mayor extensibilidad y escalabilidad.
¿Te interesa profundizar aún más en este principio de arquitectura? Este artículo te será de gran ayuda. Exploremos de forma breve y concisa cada uno de los componentes principales de la arquitectura hexagonal.
Capa de presentación
Es sencillamente la interfaz de usuario final. A grandes rasgos, se encarga de mostrar la información al usuario, interpretar sus órdenes y desencadenar las acciones de negocio pertinentes a través de su comunicación al resto de capas intervinientes.
Cabe destacar en este punto que, en ocasiones y con mucha asiduidad, se identifica al usuario o actor externo con un ser humano. Nada más lejos de la realidad. El usuario final puede ser cualquier otra entidad: una máquina, un dispositivo IoT, otro sistema informático, etc. Es un punto a tener muy en cuenta de cara al diseño de esta capa.
Capa de aplicación
Define las tareas que debe realizar el software y dirige los objetos de dominio expresivo para resolver los problemas. Las tareas de las que se encarga esta capa son significativas para el negocio o necesarias para la interacción con las capas de aplicación de otros sistemas.
Esta capa se mantiene «delgada». No contiene reglas de negocio o conocimiento, sino que sólo coordina las tareas y delega el trabajo a las colaboraciones de los objetos de dominio en la capa siguiente. No tiene estado que refleje la situación del negocio, pero puede tener estado que refleje el progreso de una tarea para el usuario o el programa.
Capa de dominio
O también llamada capa de modelo. Es el componente de la arquitectura responsable de representar los conceptos del negocio, la información sobre la situación del negocio y las reglas del negocio. El estado que refleja la situación de la empresa a través de su sistema digital se controla y utiliza aquí, aunque los detalles técnicos de su almacenamiento se delegan en la infraestructura.
En definitiva, es el componente que implementa los flujos de trabajo o producción de la compañía a través de un lenguaje muy próximo al empresarial.
Capa de infraestructura
Esta capa proporciona las capacidades técnicas genéricas que soportan las capas superiores: envío de mensajes para la aplicación, persistencia para el dominio, dibujo de widgets para la UI, etc. Asimismo, es la responsable de la conexión con los sistemas/agentes externos a nuestro dominio.
La capa de infraestructura también puede soportar el patrón de interacciones entre las cuatro capas a través de un marco arquitectónico y es también llamada capa de anticorrupción en cuanto a que evita que las capas de negocio se «contaminen» con elementos en realidad ajenos a éste.
¿Quieres más información? Echa un vistazo a esta entrada.
En el próximo capítulo de esta serie, se planteará un problema real y el diseño de la solución aplicando éste y otros principios.
CONOCIMIENTO / Descargables
EBook gratuito
eficiencia OEE
Descubre las particularidades del indicador OEE, cómo automatizar su cálculo y que requisitos deben cumplir tus procesos de producción para implementarlo.