En una aplicación donde el diseño esta orientado al dominio (Domain design Driven o DDD), termino que introdujo Eric Evans en su libro, el dominio debe ser lo más importante de una aplicación, es su corazón.
¿Que es el dominio?
El dominio es modelo de una aplicación y su comportamiento, donde se definen los procesos y la reglas de negocio al que esta enfocada la aplicación, es la funcionalidad que se puede hablar con un experto del negocio o analista funcional, esta lógica no depende de ninguna tecnología como por ejemplo si los datos se persisten en una base de datos, si esta base de datos es SQL Server, Neo4j, MongoDB o la que sea y lo que es más importante, esta lógica no debe ser reescrita o modificada porque se cambie una tecnología específica en una aplicación.
En un diseño orientado al dominio lo dependiente de la tecnología reside en el exterior como si capas de una cebolla fueran, donde podemos sustituir una capa por otra utilizando otra tecnología y la funcionalidad de la aplicación no se ve comprometida.
La arquitectura en capas es una buena forma de representar un diseño orientado al dominio, abstrayendo cada capa mediante interfaces, de forma que no haya referencias directas entre la implementación real de las capas, lo que nos va a permitir reemplazar capas en el futuro de una forma más segura y menos traumática.
En una arquitectura en capas el dominio reside en la capa más profunda o core, donde no depende de ninguna otra.
Ejemplo de dominio
Veamos unos ejemplos de requisitos y que objetos podríamos identificar pertenecientes al dominio.
En la web para poder registrar un usuario es necesario tener unos valores del usuario cumplimentados como pueden ser el nombre de usuario,email y contraseña
Este requisito podemos intuir que debe de existir un objeto usuario, seguramente una entidad, que mínimo va a tener 3 atributos, nombre de usuario, email y contraseña. La validación de los campos obligatorios debe residir en la propia entidad para evitar tener Anemic Domain Model, que es tener entidades sin comportamiento. La validación de campos obligatorios de una entidad es el comportamiento básico que una entidad puede tener, de no hacerlo la entidad, que tiene toda la información para poder hacerlo que son sus atributos, estaríamos delegando esta validación exclusivamente en el cliente consumidor de esta entidad como puede ser por ejemplo un cliente javascript, si más adelante nuestra aplicación evoluciona a publicar una Api para que otras aplicaciones puedan registrar usuarios mediante esta API, estaríamos forzando a que estos clientes realicen la validación de campos obligatorios, o lo que es peor, podría no existir esta validación.
Esta entidad usuario es un ejemplo de modelo de dominio que además tiene comportamiento o reglas de negocio como es la validación de un usuario para poder darse de alta.
Os dejo unos enlaces de ejemplos de arquitecturas orientadas al dominio, en futuros post entrare más en detalle con ejemplos sobre Diseño Orientado al Dominio (DDD) y sus patrones de diseño.
Ejemplos de arquitectura orientada al dominio
Jeffrey Palermo introdujo Onion Architecture
En el libro de microsoft Guía Arquitectura N-Capas Orientada al Dominio plantea también una arquitectura orientada al dominio.
En ambas arquitecturas se ve de una forma bastante clara que el dominio es el corazón de la arquitectura y no depende de ninguna capa.
Libros Relacionados
Domain-Driven Design: Tackling Complexity in the Heart of SoftwareImplementing Domain-Driven Design
Muchas gracias, muy claro el artículo
ResponderEliminarMuchas gracias, me sirvio bastante el contenido de la pagína
ResponderEliminarMuchas gracias, muy bien sintetizado.
ResponderEliminar