Domain-Driven Design

DDD no es una tecnología: es dejar que el negocio decida los límites del software. Learning Domain-Driven Design, de Vlad Khononov, lo presenta como herramientas estratégicas y tácticas para alinear la arquitectura con la estrategia del negocio.

Estrategia

El lenguaje ubicuo es un vocabulario compartido entre quienes desarrollan y quienes conocen el negocio. No es un glosario en un wiki: aparece en las conversaciones, en el modelo y en el código.

Un dominio se divide en subdominios: core (lo que diferencia a la empresa), supporting (necesario pero no diferenciador) y generic (capacidades comunes, muchas veces compradas hechas).

Un bounded context es el límite donde un modelo y su lenguaje son consistentes. Dos contextos pueden usar la misma palabra con significados distintos: el error es forzar un modelo único para toda la organización.

Táctica

Una entidad se define por la continuidad de su identidad; un value object, por sus atributos, y suele ser inmutable. Un agregado es un grupo de objetos tratado como una unidad para los cambios de datos, con una raíz que es la única puerta de entrada. Dos reglas canónicas: referenciar otros agregados por identidad y modificar un agregado por transacción.

DDD no exige event sourcing: los patrones tácticos son independientes de la persistencia.

Context mapping

Partnership, shared kernel, customer-supplier, conformist, anticorruption layer, open host service, published language y separate ways describen relaciones entre contextos y, sobre todo, entre equipos.