Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Información general
Diseño basado en dominios (DDD)
En el diseño impulsado por dominios (DDD)
En DDD, los arquitectos descomponen la solución en contextos acotados mediante la descomposición basada en la lógica empresarial en lugar de la descomposición técnica. Los beneficios de este enfoque se analizan en laResultados de negocio específicos sección.
El DDD es más fácil de implementar cuando los equipos utilizan una arquitectura hexagonal. En la arquitectura hexagonal, el núcleo de la aplicación es el centro de la aplicación. Está desacoplado de otros módulos a través de puertos y adaptadores, y no depende de otros módulos. Esto se alinea perfectamente con el DDD, donde un dominio es el núcleo de la aplicación que resuelve un problema empresarial. Esta guía propone un enfoque en el que se modela el núcleo de la arquitectura hexagonal como el modelo de dominio de un contexto acotado. La siguiente sección describe la arquitectura hexagonal con más detalle.
Esta guía no cubre todos los aspectos del DDD, que es un tema muy amplio. Para obtener una mejor comprensión, puede revisar los recursos de DDD que figuran en el sitio web de Domain Language
Arquitectura hexagonal
La arquitectura hexagonal, también conocida como puertos y adaptadores o arquitectura de cebolla, es un principio de gestión de la inversión de dependencias en proyectos de software. La arquitectura hexagonal promueve un fuerte enfoque en la lógica empresarial del dominio principal al desarrollar software y trata los puntos de integración externos como secundarios. La arquitectura hexagonal ayuda a los ingenieros de software a adoptar buenas prácticas, como el desarrollo basado en pruebas (TDD), lo que, a su vez, promueve la evolución de la arquitectura
Comparemos la arquitectura hexagonal con la arquitectura estratificada clásica, que es la opción más popular para modelar proyectos de software estructurado. Existen diferencias sutiles pero poderosas entre los dos enfoques.
En la arquitectura por capas, los proyectos de software se estructuran en niveles, que representan preocupaciones amplias, como la lógica empresarial o la lógica de presentación. Esta arquitectura utiliza una jerarquía de dependencias, en la que las capas superiores dependen de las capas inferiores, pero no al revés. En el siguiente diagrama, la capa de presentación es responsable de las interacciones de los usuarios, por lo que incluye la interfaz de usuario, las API, las interfaces de línea de comandos y componentes similares. La capa de presentación depende de la capa empresarial, que implementa la lógica de dominio. La capa empresarial, a su vez, depende de la capa de acceso a los datos y de varios servicios externos.
La principal desventaja de esta configuración es la estructura de dependencias. Por ejemplo, si el modelo de almacenamiento de datos en la base de datos cambia, esto afecta a la interfaz de acceso a los datos. Cualquier cambio en el modelo de datos también afecta a la capa empresarial, que depende de la interfaz de acceso a los datos. Como resultado, los ingenieros de software no pueden realizar ningún cambio en la infraestructura sin afectar a la lógica del dominio. Esto, a su vez, aumenta la probabilidad de errores de regresión.
La arquitectura hexagonal define las relaciones de dependencia de una manera diferente, como se ilustra en el siguiente diagrama. Concentra la toma de decisiones en torno a la lógica empresarial del dominio, que define todas las interfaces. Los componentes externos interactúan con la lógica empresarial a través de interfaces denominadas puertos. Los puertos son abstracciones que definen las interacciones del dominio con el mundo externo. Cada componente de la infraestructura debe implementar esos puertos, de modo que los cambios en esos componentes ya no afecten a la lógica del dominio principal.
Los componentes circundantes se denominan adaptadores. Un adaptador es un proxy entre el mundo externo y el mundo interno e implementa un puerto definido en el dominio. Los adaptadores se pueden clasificar en dos grupos: primarios y secundarios. Los adaptadores principales son los puntos de entrada al componente de software. Permiten a los actores, usuarios y servicios externos interactuar con la lógica central. AWS Lambdaes un buen ejemplo de adaptador primario. Se integra con variosAWS servicios que pueden invocar las funciones Lambda como puntos de entrada. Los adaptadores secundarios son contenedores de bibliotecas de servicios externos que gestionan las comunicaciones con el mundo externo. Un buen ejemplo de adaptador secundario es un cliente Amazon DynamoDB para el acceso a los datos.
Resultados de negocio específicos
La arquitectura hexagonal que se analiza en esta guía le ayuda a lograr los siguientes objetivos:
Estos procesos se describe detalladamente en las siguientes secciones.
