DDD(DDD)

Domain-Driven Design (DDD) es la aproximación al diseño de software que Eric Evans formalizó en su libro de 2003 con un mensaje central: el éxito de un sistema complejo depende más de modelar bien el dominio del negocio que de elegir bien la tecnología. DDD propone trabajar con los expertos de negocio para descubrir un "lenguaje ubicuo" (mismas palabras, mismos conceptos, en negocio y en código), descomponer el dominio en "bounded contexts" (espacios donde un término tiene un significado preciso) y modelar dentro de cada contexto con patrones tácticos.

Los patrones tácticos clave son: entidades (objetos con identidad y ciclo de vida), value objects (objetos inmutables sin identidad: dinero, dirección, intervalo), agregados (clusters de entidades y value objects que se modifican como una unidad transaccional con un único punto de entrada, el aggregate root), servicios de dominio (lógica que no encaja en una entidad concreta) y eventos de dominio (hechos relevantes del negocio que se publican para reaccionar fuera del agregado).

A nivel estratégico, DDD propone mapas de contexto (relaciones entre bounded contexts: shared kernel, customer-supplier, conformist, anti-corruption layer) que hacen explícitas las dependencias entre subsistemas. Esto es especialmente útil cuando los bounded contexts cruzan equipos o cuando se integra con sistemas heredados; el anti-corruption layer, por ejemplo, traduce conceptos del sistema externo a los del propio dominio sin contaminarlo.

En 10Code aplicamos DDD en proyectos con dominio rico: banca, seguros, salud, e-commerce avanzado, plataformas verticales. La inversión en descubrir y modelar el dominio antes de escribir código se recupera con creces en velocidad de iteración, claridad arquitectónica y resistencia a cambios. Para CRUD sencillos seguimos diseños más livianos: DDD aporta cuando el dominio es realmente complejo.