Diseño estratégico guiado por el dominio: contextos delimitados y mapas de contextos

Por qué el diseño guiado por el dominio tiene su lugar en un capítulo sobre estructura

Todos los estilos de este capítulo necesitan límites. Un monolito modular necesita límites entre módulos; los microservicios del Capítulo 6 necesitan límites entre servicios; incluso una aplicación hexagonal necesita saber qué pertenece al interior del hexágono. El diseño guiado por el dominio (DDD) es el método más usado para encontrar esos límites en el propio dominio de negocio, y no en capas técnicas.

Eric Evans lo presentó en Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003). Su argumento es que, en la mayor parte del software de negocio, los problemas más difíciles no son técnicos, sino de comprensión del dominio: qué es realmente una póliza, un siniestro, una entrega o un reembolso, y qué reglas lo rigen. Por tanto, el software debería construirse en torno a un modelo del dominio diseñado de forma deliberada, desarrollado conjuntamente por desarrolladores y expertos del dominio, y ese modelo debería protegerse para que no se confunda con otros modelos. En 2015 Evans publicó una breve DDD Reference que resume los patrones y añade algunos, como la asociación (partnership) y la gran bola de barro (big ball of mud) como patrones del mapa de contextos, y los eventos de dominio como pieza básica.

El DDD tiene dos mitades. El diseño estratégico divide un dominio grande en subdominios y contextos delimitados y traza las relaciones entre ellos; es arquitectura, y es el tema principal aquí. El diseño táctico ofrece piezas básicas (entidades, objetos de valor, agregados y otras) para escribir el modelo dentro de un contexto; es diseño, y se trata brevemente.

Lenguaje ubicuo

Un lenguaje ubicuo es un vocabulario compartido, construido entre desarrolladores y expertos del dominio, que se usa de forma coherente en las conversaciones, los documentos, las pruebas y el código. Si los despachadores dicen que un repartidor va "apilado" cuando lleva dos pedidos del mismo restaurante, entonces el código dice stack, no multiOrderAssignment. Cuando un término resulta ambiguo o incómodo, el equipo cambia el lenguaje y el código a la vez.

Parece una cuestión de nombres, pero tiene consecuencias arquitectónicas. La traducción entre las palabras del negocio y las palabras del código es donde nacen los malentendidos y, por tanto, los defectos. Y en el momento en que dos grupos usan la misma palabra con significados distintos, has encontrado indicios de dos modelos diferentes, que es el punto de partida de los contextos delimitados.

Subdominios: centrales, de soporte y genéricos

El dominio de negocio en su conjunto se divide en subdominios: áreas de actividad como las cartas, los pedidos, los pagos y el despacho. Los profesionales los clasifican en tres tipos, a partir de la distinción de Evans entre el dominio central y los subdominios genéricos; la división en tres con los subdominios de soporte la popularizaron autores posteriores, en especial Vaughn Vernon en Implementing Domain-Driven Design (2013).

El dominio central (core domain) es lo que diferencia al negocio de sus competidores y la razón por la que merece la pena construir el software. Para una empresa de reparto de comida, probablemente sea el despacho: asignar pedidos a repartidores y predecir las horas de llegada. Un subdominio de soporte es específico del negocio y necesario, pero no es una fuente de ventaja: la gestión de cartas, el alta de repartidores. Un subdominio genérico es un problema que comparten muchas empresas y para el que existen buenas soluciones: pagos, identidad, correo electrónico y SMS.

La clasificación es una decisión de inversión. El dominio central merece a las personas con más experiencia, el modelado más rico y un código que sea totalmente propio, porque ahí es donde un software mejor se convierte directamente en ventaja para el negocio. Los subdominios de soporte merecen diseños sólidos pero más sencillos, a menudo un módulo en capas sin complicaciones. Los subdominios genéricos normalmente deberían comprarse, usarse como servicio o construirse como adaptadores finos sobre componentes de código abierto: construir tu propio proveedor de identidad es esfuerzo invertido donde no puedes ganar. La clasificación también cambia con el tiempo; una capacidad de soporte puede pasar a ser central cuando cambia la estrategia del negocio.

Contextos delimitados

Un contexto delimitado (bounded context) es un límite explícito dentro del cual un modelo, y un lenguaje ubicuo, se aplica de forma coherente. Dentro de él, "pedido" tiene exactamente un significado. Fuera de él, la misma palabra puede significar otra cosa, y eso es aceptable, porque cada modelo está diseñado para un propósito. Evans observó que intentar unificar en uno solo el modelo de un sistema grande no es ni viable ni rentable; el intento produce enormes clases compartidas que sirven mal a todos los propósitos y que todos los equipos tienen que modificar.

Los subdominios y los contextos delimitados son cosas distintas, aunque a menudo coinciden. Un subdominio es parte del problema: existe en el negocio haya o no software. Un contexto delimitado es parte de la solución: un límite que eliges para un modelo y, normalmente, para un código y unos datos que pertenecen a un equipo. Lo ideal es un contexto delimitado por subdominio, pero los sistemas heredados suelen tener un contexto que abarca varios subdominios, y un subdominio grande puede necesitar varios contextos.

Mapas de contextos

Un mapa de contextos muestra los contextos delimitados de un sistema y las relaciones entre ellos. Las relaciones describen tanto la integración técnica como el poder y la comunicación entre los equipos, por eso el mapeo de contextos trata tanto de organizaciones como de código. Es una aplicación directa de la ley de Conway: el mapa muestra dónde deben coincidir los caminos de comunicación de la organización y los caminos de integración del sistema.

Muchas relaciones son upstream/downstream (aguas arriba/aguas abajo): las decisiones del contexto upstream afectan al downstream, pero no al revés. El equipo downstream tiene entonces que elegir cómo arreglárselas, y esa elección es lo que nombra la mayoría de los patrones.

Dos de estos patrones merecen especial atención. Una capa anticorrupción (ACL) es un conjunto de adaptadores y traductores que construye un contexto downstream para que un modelo ajeno, a menudo un sistema heredado o un proveedor externo, no pueda filtrarse en su propio modelo. Es la misma idea que el adaptador conducido de la Sección 5.6, aplicada entre contextos, y es la opción por defecto para integrarse con cualquier cosa que no controlas. Un servicio de host abierto (open host service) junto con un lenguaje publicado es la forma que tiene el contexto upstream de servir bien a muchos consumidores: un único protocolo documentado y versionado en lugar de una integración a medida para cada uno. Un núcleo compartido (shared kernel) debe seguir siendo pequeño; uno grande vuelve a convertir dos contextos en uno con dos equipos discutiendo por él, y la referencia de Evans de 2015 añade la gran bola de barro (big ball of mud) como etiqueta honesta para una zona sin ningún límite claro, que hay que contener en lugar de ampliar.

Event storming: descubrir los contextos

Los límites se descubren con los expertos del dominio, no se diseñan en solitario. El event storming, creado por Alberto Brandolini y descrito por primera vez en su blog en 2013, es el formato de taller más popular para ello. Las personas que conocen el negocio y las que construyen el software se colocan ante una larga pared de papel y escriben eventos de dominio (cosas que han pasado, en pasado: Pedido realizado, Repartidor asignado, Comida recogida) en notas adhesivas naranjas, que colocan en una línea de tiempo.

Después, el grupo añade los comandos que causan los eventos, las personas y los sistemas externos implicados, las políticas que reaccionan a los eventos ("cada vez que se realiza un pedido, buscar un repartidor") y, lo que es crucial, los puntos calientes (hot spots) donde la gente no está de acuerdo o nadie lo sabe. Los grupos de eventos que comparten un lenguaje y un propósito sugieren contextos delimitados; los lugares donde la misma palabra se usa de forma distinta sugieren límites; los lugares donde se produce un traspaso sugieren puntos de integración. Una sesión de visión global (big picture) para todo un negocio dura uno o dos días y casi no necesita más preparación que las personas adecuadas y mucho espacio en la pared.

Los patrones tácticos, en breve

Dentro de un contexto delimitado, el DDD ofrece piezas básicas para el modelo. Una entidad tiene una identidad que persiste mientras cambian sus atributos: un pedido es el mismo pedido después de que cambie su estado. Un objeto de valor no tiene identidad y se define solo por sus valores: dos objetos Money(12.50, "GBP") son intercambiables, y los objetos de valor suelen ser inmutables. Un evento de dominio registra algo significativo que ha pasado en el dominio.

Un agregado es un grupo de entidades y objetos de valor que se trata como una sola unidad para los cambios, con una entidad como raíz. El código externo solo puede guardar referencias a la raíz y solo debe modificar el agregado a través de ella, de modo que la raíz pueda hacer cumplir las invariantes del agregado (reglas que deben cumplirse siempre, como "no se pueden añadir artículos después de realizar un pedido"). Una transacción debería modificar un solo agregado; a los demás agregados se les hace referencia por su ID y se actualizan mediante eventos de dominio, lo que convierte a los agregados en la unidad natural de consistencia y, más adelante, de distribución. Un repositorio carga y guarda agregados completos y, para el dominio, parece una colección; su interfaz es un puerto conducido en términos hexagonales.

from dataclasses import dataclass, field
from decimal import Decimal

@dataclass(frozen=True)
class Money:                               # value object: equal if values equal
    amount: Decimal
    currency: str
    def __add__(self, other):
        if other.currency != self.currency:
            raise ValueError("currency mismatch")
        return Money(self.amount + other.amount, self.currency)
    def times(self, n: int):
        return Money(self.amount * n, self.currency)

@dataclass
class OrderLine:                           # entity inside the aggregate
    dish_id: str
    qty: int
    price: Money

@dataclass
class Order:                               # aggregate root
    id: str
    restaurant_id: str                     # other aggregates referenced by ID only
    lines: list[OrderLine] = field(default_factory=list)
    status: str = "draft"
    events: list = field(default_factory=list)

    def add(self, dish_id, qty, price):
        if self.status != "draft":
            raise ValueError("order already placed")    # invariant
        self.lines.append(OrderLine(dish_id, qty, price))

    def place(self, minimum: Money):
        total = Money(Decimal(0), minimum.currency)
        for line in self.lines:
            total = total + line.price.times(line.qty)
        if total.amount < minimum.amount:
            raise ValueError("below restaurant minimum")  # invariant
        self.status = "placed"
        self.events.append({"type": "OrderPlaced", "order_id": self.id, "total": str(total.amount)})

El ejemplo mantiene pequeño el agregado, hace referencia al restaurante por su ID en lugar de contener un objeto restaurante y hace cumplir sus reglas en métodos en lugar de dejárselas a quien lo llama. Un error habitual es lo contrario: agregados tan grandes que el cambio de cualquier usuario bloquea las mismas filas, u objetos de dominio que son solo bolsas de getters y setters mientras las reglas viven en clases de servicio (Martin Fowler lo llama modelo de dominio anémico).

Los contextos delimitados como límites de módulos y servicios

Los contextos delimitados son la mejor guía disponible para decidir dónde trazar los límites de los módulos en un monolito y los límites de los servicios en un sistema distribuido. Un contexto tiene su propio modelo, su propio lenguaje, sus propios datos e, idealmente, un único equipo propietario, que son exactamente las propiedades que hacen que un módulo sea cohesivo y esté poco acoplado. En un monolito modular, cada contexto se convierte en un módulo con su propio esquema; dentro de él, la estructura hexagonal de la Sección 5.6 mantiene el modelo independiente de la infraestructura.

Si más adelante hay que desplegar un contexto por separado, su límite ya tiene la forma adecuada para un servicio, y sus relaciones en el mapa de contextos te dicen cómo debe ser la integración. Por eso muchos profesionales recomiendan encontrar primero los contextos y decidir después el despliegue. Lo contrario también se cumple: los servicios que atraviesan los contextos delimitados (un "servicio de pedidos" en el que escriben todos los contextos) producen el monolito distribuido fuertemente acoplado que se trata en la Sección 6.3. Ten en cuenta también que un contexto delimitado no es automáticamente un microservicio; un contexto puede desplegarse como varios servicios, y varios contextos pequeños pueden compartir un mismo despliegue.