Domain-Driven Design (DDD)
Modelar el software alrededor del dominio, sus límites, lenguaje y reglas, en lugar de organizarlo solo por tecnología.
Qué resuelve
El lenguaje ubicuo alinea a expertos de negocio y equipo técnico; bounded contexts separan modelos que no deben compartir el mismo significado.
Entidades, value objects, aggregates, domain services y domain events expresan reglas e invariantes en el modelo.
Cuándo tiene sentido
Cuando el dominio tiene reglas complejas, vocabulario ambiguo o múltiples equipos que necesitan evolucionar de forma independiente.
DDD no exige microservicios: sus bounded contexts pueden vivir dentro de un monolito modular.
Compensaciones
Requiere colaboración continua con expertos del dominio y disciplina para no convertir cada tabla en una entidad rica artificial.
Un aggregate demasiado grande aumenta contención; uno demasiado pequeño rompe invariantes y empuja consistencia al proceso distribuido.
Comentarios