¿Realmente vale la pena el diseño impulsado por dominio? ¿O es solo para crear zumbido?

Answer 1

AnemicModel no es lo primero a considerar. DDD aborda cuestiones más importantes primero;

DDD se trata de abstraer la lógica de dominio de los aspectos tecnológicos. Las clases “Manager / helper” generalmente contienen dependencias de la capa de aplicación / servicio, como consulta db, transacciones, registrador, etc. Cuando los requisitos de la aplicación y del dominio son lo suficientemente complejos, es muy probable que este enfoque sufra en términos de mantenibilidad y extensibilidad. Puedo sugerirle que se haga las siguientes preguntas:

• ¿Puedo usar mis objetos de dominio actuales directamente (ver principio abierto-cerrado) en requisitos de aplicación totalmente diferentes? (Usando el mismo dominio.dll / jar en la base de datos mínima en memoria usando la aplicación móvil, por ejemplo)
• ¿Puedo escribir una prueba en cualquiera de esas clases manager / helper sin burlarse / tropezar con ninguna dependencia?

Si ambas respuestas son afirmativas, tienes razón, no está tan mal. Solo tiene un problema de AnemicModel. Se trata más de la discusión del purismo de objetos.

Answer 2

Domain Driven Design simplemente proporciona métodos estratégicos y tácticos para crear software empresarial. En algunas situaciones, puede ayudar. En algunas situaciones, no puede ayudar. En algunas situaciones, puede ayudar pero ser demasiado costoso. En algunas situaciones, es absolutamente necesario usarlo.

En su ejemplo particular, parece tener una situación en la que DDD podría ayudar pero sería demasiado costoso aplicarlo; entonces, sospecho que no tienes reglas comerciales muy complicadas.

DDD paga dividendos cuando tiene una aplicación con reglas comerciales sofisticadas que deben ser consistentes cerca del 100% del tiempo.

Un modelo de datos anémicos dispersará la lógica / algoritmos de dominio por todo el lugar. Esto hace que un modelo de datos anémicos sea muy costoso de mantener y muy propenso a errores al cambiar.

Imagine tener que actualizar el código en 50 lugares diferentes para una sola solicitud de cambio, y no tiene medios formales para garantizar la corrección. Ese no es el tipo de código que desea cuando el negocio cambia constantemente y prueba cosas nuevas.

Sin embargo, cuando comienzas a mover más comportamiento hacia los “agregados” y lejos de los “límites”, entonces cambiar el código se vuelve menos riesgoso. Definir los “invariantes” de su aplicación con “agregados” y “objetos de valor” hace que hablar, razonar y probar el comportamiento esperado de su sistema sea mucho más fácil.

Esto es lo que le da a DDD su ventaja competitiva.

Debe determinar si tiene sentido utilizarlo caso por caso y cuándo tiene sentido.

Answer 3

He leído dos libros famosos sobre DDD. Y como equipo obtuvimos capacitaciones DDD de “expertos”.

Puedo decir que es como filosofía. Hay muchas palabras de moda, las ideas no son claras, la implementación no es clara. Va en contra del principio de YAGNI, porque necesita crear muchas capas y el código se vuelve difícil de leer. Requiere mucho tiempo de desarrollo y hardware.

Ninguna de las grandes compañías tecnológicas tiene una presentación sobre DDD. Es popular entre los consultores, porque tienen algo nuevo que vender. Todo se ve bien entre presentaciones.

“Lenguaje ubicuo”, incluso el término no está claro. ¿Por qué no es “lenguaje explícito”? Y los libros están llenos de nuevos términos. En cada página ves un nuevo término. Cuando critica a DDD, los defensores dicen que se trata de la dinámica del equipo, la gestión de proyectos, el pensamiento empresarial primero … Para mí, DDD es un concepto vago, lleno de términos, muchas promesas de marketing y los consultores lo adoran. Hasta que algún equipo de Facebook, Google, Amazon, Apple, Twitter, Tumbler use DDD y logre buenos resultados, prefiero ignorarlo.