Domain-Driven Design
DDD es una forma de mantener el lenguaje del negocio dentro del código. No es un catálogo de patrones tácticos para esparcir sobre una app CRUD.
Experiencia personal
Ecommerce (Armirene, Kooomo, Zerogrey) y un ERP privado (Soga / ProCrédito v2) son dominios donde el lenguaje ya existe en el negocio. El procesamiento de obligaciones es un bounded context: Laravel posee el agregado; los workers en Python transforman archivos y streams sin convertirse en el dominio.
Perspectiva técnica
Empieza por bounded contexts, no por agregados. Si “orden” significa tres cosas distintas para ventas, bodega y finanzas, no tienes un modelo con campos extra. Tienes tres modelos que comparten una palabra.
Los patrones tácticos — entidades, value objects, eventos de dominio — son útiles después de que el mapa de contextos es honesto. Aplicados primero, producen ceremonia alrededor de una sola base de datos.
La capa de dominio no debería importar el framework web, el ORM ni el broker. Eso no es pureza por sí misma. Es cómo mantienes un modelo testeable cuando cambia la infraestructura, que va a cambiar.