Strategic Design
El Diseño Estratégico en DDD es un conjunto de principios y patrones que orientan la estructura y la interacción de los modelos de dominio a nivel de sistema o proyecto. Estos elementos estratégicos ayudan a manejar la complejidad en organizaciones grandes y sistemas de software, enfocándose en la alineación de los modelos de negocio con la implementación técnica.
Elementos estratégicos del DDD
Ubiquitous Language:
El Lenguaje Ubicuo es un lenguaje compartido utilizado por todos los miembros del equipo, tanto técnicos como no técnicos, para garantizar una comunicación clara y efectiva. Define todos los términos y actividades del dominio, y está presente en todas las capas de la aplicación.
Bounded Context:
Los Contextos Delimitados son una clara demarcación dentro del dominio donde un modelo particular es definido y aplicado. Dentro de un contexto delimitado, todos los términos, conceptos y reglas del dominio aplican de forma coherente, pero estos pueden cambiar significativamente en otros contextos. En el siguiente ejemplo, ShoppingCart es un bounded context estructurado en capas según la arquitectura hexagonal.
DirectoryShoppingCart Bounded Context
DirectoryApplication
- AddProductToCart.php
- RemoveProductFromCart.php
DirectoryDomain
- Cart.php
- Product.php
- CartRepository.php Interfaz (contrato de dominio)
DirectoryInfrastructure
- InMemoryCartRepository.php
- DoctrineCartRepository.php
Context Map
El Context Map es un panorama visual o descriptivo que muestra un mapa global de los diferentes Bounded Contexts, es decir, un esquematización del modelo real para ayudar a estructurar el código.
Big Ball of Mud y Anticorruption Layer
La Big Ball of Mud es una metáfora que describe un sistema de software monolítico y desorganizado, donde las reglas de negocio, la lógica de presentación y la infraestructura están entrelazadas y son difíciles de separar. Este patrón es un anti-patrón que se debe evitar en el diseño de software. Pero a veces, es inevitable en sistemas heredados. En estos casos, se suelen usar capas de contención (Anti Corruption Layer) para evitar que la “bola de barro” contamine los nuevos sistemas. Una Anticorruption Layer no es más una capa que se coloca entre dos contextos para prevenir que un modelo o conceptos no deseados contaminen otro contexto. O Dicho de otro modo, una API o interface que sirve para comunicar con el sistema heredado. De esta forma conseguimos dos beneficios: a) ni modificamos ni mantenemos el código heredado (que si lo hacemos, lo más normal es que falle) y b) evitamos que los nuevos sistemas se vean contaminados por los sistemas heredados.
Continuous Integration
La Continuous Integration asegura que a medida que los modelos evolucionan y se refinan, los cambios se integren de manera continua a lo largo de los diferentes contextos y equipos. Este enfoque promueve la coherencia y ayuda a evitar la fragmentación y los “silos” de conocimiento. Es decir, viene a promover que los cambios que surgen en el modelo real, se puedan integrar de forma continua en el modelo de software.
Shared Kernel
El Shared Kernel es un modelo compartido entre dos o más Bounded Contexts que proporciona un terreno común y evita la duplicación de esfuerzos. Este kernel compartido incluye elementos del modelo y del código que ambos contextos acuerdan compartir.
Customer/Supplier Teams
En los patrones de Customer/Supplier Teams, un Bounded Context actúa como cliente y otro como proveedor. Este patrón establece una relación clara de flujo de trabajo y dependencia entre dos contextos, donde el equipo proveedor debe satisfacer las necesidades del equipo cliente. Esto sule ser común cuando un equipo de desarrollo se encarga de desarrollar un API para que otro equipo pueda consumirlo, por lo que el desarrollo viene dado por las necesidades del sistema consumidor.
Published Language
El Published Language es un lenguaje común y compartido que se publica y se mantiene actualizado para que todos los equipos y contextos puedan acceder a él. Este lenguaje común ayuda a mantener la coherencia y la alineación entre los diferentes contextos. O dicho de otro modo, es la documentación que se va generando a medida que se va desarrollando el software. Esta documentación debe ser accesible para todos los equipos y contextos, no solo para los desarrolladores, de este modo, se garantiza que todos los miembros del equipo estén alineados con el modelo de negocio.
Open Host Service
El Open Host Service expone un conjunto de servicios que otros Bounded Contexts pueden consumir, actuando como un anfitrión que ofrece funcionalidades a través de una interfaz claramente definida. Este concepto hay que cogerlo con pizas, es decir, debe ser utilizado realmente cuando sea justificable, pero exponer APIs sin sentido en los bounded context para establecer así comunicación entre ellos, podría llevar a la creación de un Big Ball of Mud.
Separate Ways
El patrón de Separate Ways sugiere que cuando la integración entre Bounded Contexts es demasiado compleja o innecesaria, es preferible que los contextos sigan caminos separados y eviten la integración forzada.
Conformist
El patrón Conformist establece que un Bounded Context debe adaptarse a las reglas y restricciones de otro contexto, incluso si estas reglas no son ideales o no se ajustan perfectamente a sus necesidades. Este patrón se utiliza cuando un contexto depende de otro y no puede funcionar de forma independiente.