¿Qué hace que mi código DDD (diseño controlado por dominio) califique?

Question

Soy nuevo en DDD y estoy pensando en usar esta técnica de diseño en mi proyecto.

Sin embargo, lo que me impresiona 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, agregado de raíz) que contiene otros objetos menores (es decir, objetos de valor y entidades) en la capa de modelo para enviar datos a una vista fuertemente tipada.

Para mí, la única idea nueva en DDD es probablemente el

• entidades "inteligentes" (es decir, que se supone que tienen reglas de negocio sobre los agregados raíz)
• separación entre el objeto de valor, agregado de raíz y entidades.

¿Alguien me puede decir 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?

Answer 1

La respuesta corta es que no es lo que su código parece que lo califica como un proyecto DDD, es cómo llegó a ese código. Ahora para la versión larga ...

Tiene toda la razón de que no hay nada muy revolucionario en las prácticas de codificación DDD, pero parece que está 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á solo en la forma en que está 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.

Answer 2

DDD no es realmente una lista de verificación, es una metodología.

Además de respuesta Stefans, me gustaría sugerir la (auto de importancia) siguiente:

• lenguaje ubicuo - ¿Su código utilizan los mismos nombres/términos como el negocio ? ¿Sus objetos de dominio usan con los mismos nombres que el negocio?
• Comportamiento - ¿La mayoría de los comportamientos/lógica están asociados directamente con objetos de dominio, o tiene un montón de DTOs tontos?
• Contextos delimitados - ¿Ha definido claramente áreas de responsabilidad y Separación de preocupaciones?
• Agregados - ¿Ha identificado Agregados basados ​​en objetos raíz y las estrategias de bloqueo para imponer invariantes comerciales?
• repositorios - son todos los datos de acceso /consultar hará mediante repositorios, o tiene código SQL en otras clases?
• Servicios de dominio de - ¿Tiene servicios de dominio de lógica de negocio que no forma natural en forma en un objeto de dominio
• Especificaciones - ¿Tiene reglas de negocio muy bien envueltos en las especificaciones?
• Consultar especificaciones - ¿Tiene consultas pre-enlatadas/filtros muy bien envoltorio en las especificaciones de la consulta?

¡Luego está todo lo demás!

creo que la mayoría de los practicantes de DDD querrían decir:

"trabajo con expertos de dominio para entender sus necesidades, y escribe sistemas que (a) responden a las condiciones y procesos de negocios, (b) ayudar a otros desarrolladores comprender el dominio comercial, y (c) puede flexar para adaptarse a los cambiantes requisitos comerciales. "

Espero que ayude!