Arquitectura de capas en Domain-Driven Design

Esta vez, exploremos los conceptos de arquitectura en capas, tal como lo propuso Eric Evans en su libro clásico Domain-Driven Design, Tackling Complexity in the Heart of Software. 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.

Mi idea es tomar un ejemplo (posiblemente un dominio como uno del libro de Jimmy Nilsson), y desarrollarlo usando estas ideas, mostrando código concreto en Java y en .NET. En algún punto, discutiré sobre generación de código desde un modelo abstracto, pero no será el foco de esta serie de posts.

Fuentes consultadas:

Domain-Driven Design, Tackling Complexity in the Heart of Software, de Eric Evans.
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, de Jimmy Nilsson
.NET Domain-Driven Design with C#, Problem, Design, Solution, de Tim McCarthy. (Hay una sección en el blog de Tim dedicado a este libro).

Pueden bajar libremente

Domain-Driven Design Quickly

desde InfoQ.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com

This entry was posted in 1389, 1390, 2884, 3463, 8847. Bookmark the permalink.

One Response to Arquitectura de capas en Domain-Driven Design

  1. scritorio gráfico, o cualquier otra tecnología de presentación, presente o futura

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>