A la hora de integrar Bounded Contexts es importante recordar que los mismos deben ser autónomos. Cada uno es desarrollado de forma independiente y aislada de los demás. Su codebase puede ser evolucionado sin miedo a romper funcionalidades de otro Bounded Context. No hay dependencias de código fuente entre Bounded Contexts. Creamos estos contextos para reducir la complejidad de nuestro sistema y poder entregar valor de negocio rápidamente, por ende es muy importante intentar respetar su autonomía. A continuación vamos a ver distintas estrategias de integración técnica entre Bounded Contexts y analizar los problemas y beneficios que cada una trae.
En este post veremos como crear un Context Map (mapa de contextos) que permite visualizar las relaciones a nivel técnico y organizacional entre los distintos Bounded Contexts.
En el post anterior de esta serie vimos cómo dividir un dominio complejo en subdominios menos complejos. Cada subdominio va a tener su propio modelo, por ende vamos a tener muchos modelos conviviendo al mismo tiempo. Si tuviésemos un único modelo, los conceptos de un área de negocio se podrían confundir con conceptos similares de otras áreas y esto generaría complejidad y acoplamiento. Domain-Driven Design nos propone separar un sistema grande en muchos modelos y proteger la integridad de cada uno para que sus conceptos se mantengan aislados, consistentes y protegidos. Esto se logra encapsulando cada modelo en un Bounded Context.
Domain Driven Design (diseño dirigido por el dominio) o DDD es una filosofía de desarrollo de software que permite a los equipos manejar de forma efectiva la construcción y mantenimiento de software para dominios de problema complejos.
Los eventos de dominio (Domain Events) son uno de los patrones de diseño tácticos de Domain Driven Design (DDD).
Aparecieron posteriormente al libro azul donde Eric Evans introduce los conceptos fundamentales y tuvieron un gran impacto en la comunidad por las posibilidades que otorgan.
Desde la parte estratégica de DDD, se descubrió que para entender el problema de dominio era muy útil focalizarse en los principales eventos que ocurren en el negocio (como por ejemplo que un cliente hizo una compra o que un producto está listo para despachar).
Los eventos son grandes ordenadores de los procesos de negocio y permiten descubrir y entender flujos complejos que involucran a distintos actores.