Desde hace poco tiempo estoy
trabajando con “arquitectura DDD”, y con este post pretendo hacer una breve
introducción a este tipo de arquitectura y explicar la funcionalidad de cada
una de sus capas. No entraré en demasiados detalles técnicos, para eso ya
existen libros donde profundizar mucho más en este tipo de arquitectura.
¿Qué es DDD (Domain Driven Design)?
Es un tipo de arquitectura de
software orientada a dominio (ámbito para el cual estamos desarrollando la
aplicación), donde éste es el que se encargará de guiar el desarrollo del
software. El objetivo principal es conseguir tener un modelo de dominio rico y
que vaya creciendo poco a poco con las nuevas implementaciones.
¿Qué
es el Dominio?
El dominio es donde se definen
los procesos y las reglas de negocio de nuestra aplicación, es decir, es donde
se define la funcionalidad de la aplicación.
Capas
de arquitectura DDD.
Antes de nada pongamos un simple
diagrama de capas en las que se divide:
Un ejemplo de distribución de las
capas en el Visual Studio seria el
siguiente:
Ahora pasaremos a explicar cada
una de las capas empezando por la parte superior:
1.
UserInterface:
Esta será nuestra capa de presentación. Aquí pondremos nuestro proyecto MVC, ASP,
o lo que utilicemos como front-end de
nuestra aplicación.
2.
Application:
Esta capa es la que nos sirve como nexo de unión de nuestro sistema. Desde ella
se controla y manipula el domain. Por
ejemplo, dada una persona se requiere almacenar información de un hijo que
acaba de nacer. Esta capa se encargará de: llamar a los repositorios del domain para obtener la información de esa
persona, instanciar los servicios del domain
y demás componentes necesarios, y por ultimo persistir los cambios en
nuestra base de datos.
En esta capa también crearíamos interfaces e
implementaciones para servicios, DTOs etc,
en caso de que fuese necesario.
3.
Domain:
En domain podemos ver que hay 3
proyectos:
3.1.
Entities:
En el cual tendremos nuestras entidades. Es decir, es una clase donde se
definen los atributos de la entidad.
Una entidad tiene una clave que es única y la
diferencia de cualquier otra entidad. Por ejemplo, para una clase Persona, podríamos tener los siguientes
atributos: Nombre, Apellidos y fecha de nacimiento, en ellos tendríamos la información para la
clase Persona.
Una entidad no sólo se ha de ver como una simple clase
de datos, sino que se ha de interpretar como una unidad de comportamiento, en
la cual, además de las propiedades antes descritas, debe tener métodos como por
ejemplo Edad(), el cual a través de
la fecha de nacimiento tiene que ser
capaz de calcular la edad. Esto es muy importante, ya que si las entidades las
utilizamos simplemente como clases de datos estaremos cayendo en el antipatrón de modelo de datos anémico.
3.2.
Domain:
En este proyecto tendremos los métodos que no se ciñen a una entidad, sino que
lo hacen a varias. Es decir, operaciones que engloben varias entidades.
3.3.
Repositories:
Aquí expondremos la colección de métodos que consumiremos desde nuestra capa aplication. En los repositories se va a instanciar las entidades de nuestro dominio,
pero no las implementa. Para eso ya tenemos la capa de infrastructure. Por ejemplo New,
Update, Delete…
4.
Infrastructure:
Esta será la capa donde implementaremos repositorios, es decir, donde estarán
las querys que ejecutaremos sobre la
base de datos.
Espero haber “introducido” en
esta arquitectura a gente que nunca haya trabajado con ella, y sobre todo, haber
dejado claro la responsabilidad de cada una de las capas.
1 comentario:
Publicar un comentario