Blog Jose Cuellar

//Tech Lead, Senior Backend Developer & Life-long learner

Domain-Driven Design. Context Maps

por Jose el 27 julio, 2016

En el post anterior vimos los primeros pasos estratégicos y cómo disgregábamos la complejidad del negocio en Domains, Subdomains y Bounded Contexts.

Cada Bounded Context contiene o dispone de la tecnología, lenguaje de programación y arquitectura mínima necesaria para satisfacer los requerimientos de negocio de su contexto mediante un modelo de dominio. Las relaciones existentes entre Bounded Contexts se denominan Context Maps y las reglas necesarias para mapear/traducir un modelo de dominio de un determinado contexto a otro: Translation Map.

Una vez identificados los Bounded Contexts, deberemos establecer según necesidades de cada caso el tipo de relación entre ellos, marcando la dirección de flujo de información mediante Upstream (exposición de servicios) y Downstream (consumidor de servicios):


Evans, describe patrones organizativos e integración que describen los tipos de relación entre Bonded Contexts

Partnership: Ambos equipos Downstream y Upstream disponen de una fuerte y estrecha dependencia, siendo necesario planificar y sincronizar conjuntamente las actualizaciones de ambos Bounded Contexts. El desarrollo debe tener en cuenta las necesidades de ambos contextos mediante una coordinación exhaustiva entre los equipos.

Shared Kernel: Bounded Contexts que comparten/reutilizan parte del modelo de dominio, existiendo una interdependencia o un área común compartida. Dichos elementos compartidos no deberían modificarse sin consultarlo con los equipos afectados:


Fuente: Taming Complex Domains with Domain Driven Design.

Customer-Supplier Development: Un equipo gestiona los servicios del Bounded Context (Upstream) dando soporte bajo demanda según necesidades del equipo que gestiona el Bounded Context que solicita los recursos (Downstream). Se prioriza y negocia previamente la exposición de servicios para evitar las dependencias en el evolutivo de los desarrollos de los equipos que los consumen.

Conformist: El equipo gestiona y publica los servicios (Upstream) en el Bounded Context de forma desalineada con el evolutivo de cualquier otro contexto. El equipo que gestiona el Bounded Context consumidor (Downstream) se adhiere y conforma con el modelado representado en los servicios, sin necesidad de compatibilizarlos al modelado de dominio local/propio.


Fuente: Discovering the Domain Architecture.

Separate Ways: Bounded Context independiente sin ningún tipo de relación entre ningún otro. No existen integraciones, ni relaciones de ningún tipo entre los equipos de desarrollo.

Bif Ball of Mud: Monolito o Legacy Code no disgregado encapsulado/aislado en un Bounded Context compartiendo sus servicios. Controlando su crecimiento y aconsejando extraerlo en nuevos Bounded Context generando nuevos Context Maps entre los existentes.

Patrones técnicos de integración entre Bounded Contexts

Open Host Service (OHS): Define un protocolo de acceso al sistema o servicios para la integración de los requerimientos. Normalmente necesita un lenguaje de publicación común de interacción entre los modelos de dominio. Por ejemplo RPC o REST mediante API. Aunque puede implementarse mediante un middleware de mensajería como RabbitMQ.

Published Language (PL): Lenguaje común para la traducción entre los modelos que van a interaccionar. Por ejemplo JSON o XML. Normalmente asociado a OHS. La ventaja de utilizar servicios REST es que en cada petición puede especificarse el PL configurando el content type deseado.

Anticorruption Layer (ACL): Capa aislada que gestiona el mapeo o traducciones entre los modelos de dominio de los Bounded Contexts para mantener la compatibilidad entre ellos.


Fuente: Strategic Domain Driven Design with Context Mapping.

En dicha capa se implementan las interfaces expuestas como servicios de dominio. Tanto el Adaptor como el Translator de cada entidad del modelo que deseamos traducir o compatibilizar. Empleando Facade y mediante HttpClient:


Fuente: Domain-Driven Design.

Adaptor puede reemplazarse por nuevas implementaciones de Repository utilizando HttpClient para el acceso al repositorio externo mediante API.

En el siguiente diagrama vemos los Bounded Contexts y sus puntos de integración mediante OHS y PL utilizando ACL para mapear y traducir el modelo de dominio estableciendo la compatibilidad por cada tipo de entidad:

Resumen gráfico de todos los conceptos:

Hasta aquí abordo hasta el capítulo 5 de Implementing Domain-Driven Design de Vaughn Vernon. El resto se centra en los aspectos tácticos de DDD: Entities, Value Objects, Services, Domain Events, Modules, Aggregates, Factories, Repositories, etc.

Será más divertido 🙂
Coming soon…

¿Crees que hay algún aspecto estratégico importante en DDD que no menciono en ambos post y debería?

¿Tienes alguna experiencia disgregando en Bounded Contexts algún Big Ball of Mud?

One thought on “Domain-Driven Design. Context Maps

  1. Buenas, excelente publicaciones las que realiza mis felicitaciones.

    Bueno tengo dudas a nivel de código en como debería modelar una entidad cuando se encuentra en varios contextos, o sea una entidad compartida. Gracias de antemano

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.