Investigación sobre Domain Driven Design (DDD)

Diseño guiado por el dominio o Domain-driven design (DDD) es un enfoque para el desarrollo de software con necesidades complejas mediante una profunda conexión entre la implementación y los conceptos del modelo y núcleo del negocio. Las premisas del diseño guiado por el dominio son las siguientes:

• Poner el foco primario del proyecto en el núcleo y la lógica del dominio.
• Basar los diseños complejos en un modelo.
• Iniciar una creativa colaboración entre técnicos y expertos del dominio para interactuar lo mas cercano posible a los conceptos fundamentales del problema.

El diseño guiado por el dominio no es una tecnología ni una metodología, este provee una estructura de practicas y terminologías para tomar decisiones de diseño que enfoquen y aceleren el manejo de dominios complejos en los proyectos de software.
El termino fue acuñado por Eric Evans en su libro Domain-Driven Design - Tackling Complexity in the Heart of Software.


Erick Evans comienza hablando sobre como construir un lenguage comun entre los expertos del dominio o expertos del negocio para el cual se quiere diseñar un sistema, y los expertos en el diseño de sistemas. En primera instancia esto suena como a "Obvio es lo que hacemos todos los desarrolladores". Pero indagando solo un poco más profundo Evans muestra que en las sutilezas y los detalles de como hacer esto hay un mundo de diferencia que puede significar el éxito o fracaso de un sistema.

Arquitectura de capas en Domain-Driven Design

Eric Evans propuso en su libro (Domain-Driven Design, Tackling Complexity in the Heart of Software) los conceptos de arquitectura en capas, en el capítulo cuatro del libro, Evans presenta este diagrama:

Evans Escribe:

En una aplicación de carga y envío de mercadería, para simplemente listar y seleccionar el destino de la carga de una lista de ciudades, debe haber código que (1) dibuje un control en la pantalla, (2) consulte una base de datos para obtener las posibles ciudades, (3) interprete el ingreso de usuario y lo valide, (4) asocie la ciudad seleccionada con la carga, y (5) confirme el cambio en la base de datos. Todo este código es parte del mismo programa, pero sólo una pequeña parte está relacionado con el negocio de envío de cargas.

El propone que el modelo de dominio resida en una capa, la Capa de Dominio. De esta forma, el modelo de dominio es protejido de los detalles técnicos, como la implementación de la persistencia, y los detalles de presentación. Me gusta decir que el dominio es un organismo, qe recibe estímulos, acciones desde el exterior,y reacciona a esos comandos. El dominio debería ejecutarse sin conocimiento detallado del resto de la aplicación. Serialización entre capas físicas, detalles de presentación, y acceso a base de datos, deben estar claramente separados de la implementación del dominio.

Las capas puede ser descriptas como:

UI (User Interface): la más fácil de entender, esta capa es la responsable de mostra información al usuario, y aceptar nuevos datos. Puede ser implementada para web, escritorio gráfico, o cualquier otra tecnología de presentación, presente o futura. Por ejemplo, podría ser una aplicación de voz, que interactúa con el usuario usando un teléfono. La prueba ácida para nuestro diseño es que un cambio radical en la interfaz de usuario debería tener mínimo (o por lo menos, controlado) impacto en el resto del sistema.

Application Layer: está a cargo de coordinar las acciones a ser realizadas en el dominio. No tiene reglas de negocio o conocimiento del dominio. No hay estado del negocio en esta capa. Delega todas las acciones del negocio al propio dominio. Podría coordinar varias acciones (posiblemente, en varios dominios). Preara la infraestructura para que esté lista a trabajar con el dominio en una acción específica (por ejemplo, preparando la transacción que vaya a usar).

Domain Layer: En esta capa reside el corazón del software, según Evans. Las reglas y lógica de negocio residen en esta capa. Estado de entidades de negocio y su conducta es definida y usada aquí. Comunicación con otros sistemas, detalles de persistencia, son delegados en la capa de infraestructura. Evans discute los patrones que él usa en esta capa, como Entities, Value Objects, Services, Repositories y Factories. Exploraremos esos patrones y sus implementaciones en futuros posts.

Infrastructure Layer: Dios y el diablo estan en los detalles, dice el dicho, y también en la capa de infraestructura. La principal responsabilidad de esta capa es la persistencia del estado de negocio, muy frecuentemente, usando una base de datos relacional.