Domain Driven Design (DDD) en .NET
Como implementar Domain Driven Design en Proyectos .NET Core
Si quieres aprender a nivel senior Domain Driven Design y Clean Architecture con .NET, registrate en el bootcamp más completo en ASP NET Core
👉Registrate aqui: https://www.vaxidrez.com/bundles/membresia
Comenzemos el post!
Un gran problema que enfrentamos los programadores es la comprensión en los procesos de una organización que maneja su propio dialecto.
Inclusive he conocido casos donde programadores trabajan por años en una misma empresa y nunca llegan a comprender de qué trata el negocio a profundidad, solo se dedican a hacer CRUDs y tapar agujeros.
Conclusión, la brecha entre los dueños del negocio(Stakeholders) y los programadores es real.
¿DDD soluciona el problema?
DDD es un paradigma de la ingeniería de software de vital importancia en alinear los conceptos entre los stakeholders y los programadores, dando como resultado que las funcionalidades que se desarrollen estén directamente relacionadas con las necesidades de la organización o negocio.
Para empezar a comprender de qué trata DDD, veamos algunos de sus importantes conceptos y componentes:
Bounded Context
Si lo traduces de forma literal significa “Contexto Delimitados”, representa que debemos crear un ambiente donde los términos y conceptos tanto de negocio como técnicos deben compenetrarse y unirse. De esta forma tanto los Stakeholders como los programadores hablarán y comprenderán el mismo lenguaje.
A este lenguaje de negocio/técnico se le llama “ubiquitous language”.
Entities y Value Objects
Ambos componentes son la base en la definición del modelo del Domain, recuerda que llamamos Domain a todo el caso de estudio, en este caso el Domain sería la empresa u organización.
Mientras que las entidades son objetos que siempre tienen un identificador único y sus valores/estados pueden cambiar con el tiempo, por otro lado tenemos los object values que carecen de un identificador pero que describen características únicas de un objeto.
Las entidades son mutables mientras que los objetos de valor son inmutables.
Aggregates
Al conjunto de Domain Objects(Entidades y Value Objects) que pueden ser tratados como una unidad se le llama aggregate.
Dentro de un agregate puedes definir reglas/mecanismos adicionales para administrar al conjunto de objetos.
Por ejemplo puedes crear un aggregate que represente a un cliente, entonces llamamos a este aggregate Clientes y estaría conformado por dos componentes:
Entity → Cliente
Value Object → Direccion
A este aggregate le podriamos agregar un business rule, por ejemplo que los clientes solo sean de Mexico, entonces aplicamos el código de esta manera:
En la línea 17, estamos creando un Value Object llamado Direccion con dos properties, Pais y Ciudad.
En la línea 20, creamos una clase entidad “Cliente”, esta se caracteriza por tener un identificador Id, y también está incluyendo como propiedad al Value Object “Direccion”.
En la línea 28, agregamos un business rule, que indica que si el país no es Mexico entonces lanzará una excepción.
Es así como creamos un aggregation, un conjunto de objetos como Cliente y Direccion agrupados, y también agregamos cierta lógica de negocio o reglas de negocio dentro de estas definiciones.
¿Qué ventajas trae DDD?
Conectar en un lenguaje en común a ambos equipos: los programadores y los stakeholders o dueños del negocio.
Flexibilidad en el producto final, haciendo que el software desarrollado, sea fiel reflejo del modelo del dominio, esto trae como consecuencia que los futuros cambios sean sencillos de implementar y sigan los lineamientos del negocio.
¿Qué Desventajas tengo si uso DDD?
El tiempo desarrollo es mayor, por que se deben crear nuevos componentes como entidades, value objects, business rules, aggregations mas explicitamente.
Si no se tiene un Stakeholder experto en el dominio de la organización, el DDD y el software resultante se alejan de los requerimientos reales, y al contrario del objetivo final, harían que este nuevo software en vez de facilitar los procesos de la organizacion terminen complicando el alta o baja de recursos.
La complejidad en el conocimiento de DDD, requiere una curva de aprendizaje mayor que solo trabajar en el modo tradicional de modelamiento.
Entra ahora y se parte del Bootcamp en:
https://www.vaxidrez.com/bundles/membresia
