que - domain driven design pdf
¿Qué hace que mi código DDD(diseño controlado por dominio) califique? (2)
DDD no es realmente una lista de verificación, es una metodología.
Además de la respuesta de Stefans, sugeriría lo siguiente (en orden de importancia):
- Lenguaje ubicuo : ¿su código usa los mismos nombres / términos que el negocio? ¿Sus objetos de dominio usan los mismos nombres que el negocio?
- Comportamiento : ¿la mayoría de los comportamientos / lógicas están asociados directamente con los objetos de dominio, o tienes muchos DTO tontos?
- Contextos delimitados : ¿Ha definido claramente las áreas de responsabilidad y la separación de preocupaciones?
- Agregados : ¿ha identificado agregados basados en objetos raíz y las estrategias de bloqueo para imponer invariantes comerciales?
- Repositorios : ¿todo el acceso / consulta de datos se realiza a través de repositorios, o tiene código SQL en otras clases?
- Servicios de dominio : ¿tiene servicios de dominio para la lógica empresarial que no encaja naturalmente en un objeto de dominio?
- Especificaciones - ¿Tiene reglas de negocios bien envueltas en Especificaciones?
- Especificaciones de consulta : ¿tiene consultas / filtros predefinidos que se ajustan muy bien en las especificaciones de consulta?
¡Luego están todas las otras cosas!
Creo que la mayoría de los practicantes de DDD querrían decir:
" Trabajo con expertos en dominios para comprender sus necesidades y escribir sistemas que (a) coinciden con los términos y procesos de las empresas, (b) ayudar a otros desarrolladores a entender el dominio comercial y (c) pueden flexibilizarse para satisfacer los cambiantes requisitos comerciales " .
¡Espero que ayude!
Soy nuevo en DDD y estoy pensando en usar esta técnica de diseño en mi proyecto.
Sin embargo, lo que me llama la atención acerca de DDD es que tan básica es la idea. A diferencia de otras técnicas de diseño como MVC y TDD, no parece contener ideas innovadoras.
Por ejemplo, estoy seguro de que algunos de ustedes tendrán la misma sensación de que la idea de los agregados raíz y repositorios no es nada nuevo, ya que cuando está escribiendo aplicaciones web MVC, debe tener un único objeto maestro (es decir, el agregado raíz) que contienen otros objetos menores (es decir, objetos y entidades de valor) en la capa del modelo para enviar datos a una vista fuertemente tipada.
Para mí, la única idea nueva en DDD es probablemente la
- Entidades "inteligentes" (es decir, se supone que debes tener reglas comerciales sobre los agregados raíz)
- Separación entre objeto de valor, agregado de raíz y entidades.
¿Alguien puede decirme si me he perdido algo aquí? Si eso es todo lo que hay en DDD, si actualizo una de mi aplicación MVC existente con las 2 nuevas ideas anteriores, ¿puedo decir que es una aplicación TDD, MVC y DDD?
La respuesta corta es que no es a lo que se parece su código que lo califica como un proyecto DDD, sino a cómo llegó a ese código. Ahora para la versión larga ...
Tiene toda la razón en que no hay nada muy revolucionario en las prácticas de codificación de DDD, pero parece estar un poco fuera de lugar con su pregunta. Un error común que muchos desarrolladores cometen con DDD es centrarse demasiado en las prácticas de codificación sin tener en cuenta algunos de los conceptos más fundamentales de DDD. En esencia, DDD es una práctica de desarrollo iterativo de un modelo con una estrecha colaboración entre desarrolladores y expertos de dominio. Puede codificar todos los servicios, entidades y objetos de valor que desee, pero si no involucra expertos de dominio en el proceso, o no está mejorando el modelo en las repeticiones, entonces, francamente, no está practicando DDD. Incluso desde una perspectiva de codificación, muchos consideran que los conceptos de raíces agregadas, contextos acotados y capas anticorrupción son herramientas más valiosas que los patrones básicos.
No estás solo en cómo estás percibiendo DDD. Encuentro que casi todos los desarrolladores atraviesan una etapa de DDD en la que intentan implementar aplicaciones de muestra utilizando entidades, objetos de valor y servicios, mientras ignoran todas las otras prácticas que son fundamentales para DDD. DDD es un proceso diseñado para manejar la lógica empresarial compleja, por lo que juzgar sus ventajas en una aplicación de muestra desarrollada durante un fin de semana no lo expone a lo mejor que DDD tiene para ofrecer. Le insto a que continúe profundizando en DDD, ya que considero que es una herramienta indespensable, pero nunca olvide que es mucho más que un lenguaje de patrones.