¿Es DDD una pérdida de tiempo? [cerrado]

Question

Googlear " ¿Para qué tipo de aplicaciones es adecuado DDD? " Me dio la siguiente respuesta:

  

Probablemente el 95% de todas las aplicaciones de software se encuentren en & # 8220; no es tan bueno para usar DDD & # 8221; categorías. (vea el artículo )

Entonces, ¿de qué se trata todo este alboroto?!?

La aplicación en la que estoy trabajando es principalmente centrada en los datos, pero aún contiene algunas reglas y lógica de negocios que se deben aplicar. ¿Sería una pérdida de tiempo comenzar a aplicar técnicas DDD? ¿Estoy mejor usando una capa de acceso a datos más convencional, un modelo de POCO y una capa de lógica de negocios? O para decirlo de otra manera: ¿cuál es una alternativa sólida al DDD?

Answer 1

Muchos desarrolladores que piensan que DDD es útil para su proyecto caen en la trampa de que piensan de lo que se trata su trabajo es escribir código. Este no es el caso. El trabajo de un desarrollador consiste en realizar una funcionalidad para que un problema se pueda resolver a través del software. Esto lleva a la conclusión de que escribir código no es el principio de lo que hace un desarrollador, sino el final: el código es el resultado de todo el proceso ANTES de que el código esté realmente escrito.

DDD no se trata de escribir código, no es un proceso llave en mano de 10 pasos para obtener un excelente software, se trata de todo el proceso ANTES de escribir el código, se trata de obtener una idea de qué se trata el problema, qué / quién participa en qué flujos de información y cómo se ven estos elementos, cómo se relacionan entre sí, etc. etc. De hecho, la parte más importante de DDD es crear un lenguaje que posibilite las conversaciones entre expertos en dominios y desarrolladores sin malas interpretaciones . Este es el 'lenguaje ubicuo' del que habla Evans. En efecto, hace que todo el proceso ANTES de que el código se escriba, no deja mucho que adivinar, las cosas son claras y directas. (Ese es el objetivo).

El problema con '¿Cómo funciona la DDD en la práctica' y '¿Podría alguien darme un ejemplo de cómo escribo el código con DDD?' y lo que realmente se debe al hecho de que las personas que hacen este tipo de preguntas se centran en escribir código, pero no tienen idea de POR QUÉ están escribiendo ESE código y no otro código. I.o.w .: si te das cuenta de que DDD se trata de descubrir QUÉ tienes que escribir como funcionalidad y POR QUÉ, las cosas encajan en su lugar. CÓMO estás escribiendo ese código, eso depende de ti. Pero como se dijo: ese ya no es el mayor problema, ya que para entonces ya sabes lo que tienes que escribir y por qué.

Answer 2

ya sabes, a veces el 5% gana más dinero que el resto del 95%, por eso existe el DDD.

es para un sistema grande complejo específico.

Answer 3

Lo siento, pero si DDD fuera solo una forma de pensar como dice Frans Bouma, entonces no recomendaría cosas como la Ignorancia de Persistencia. Esto está descartando a los demás como desarrolladores de clase baja.

PI, para el cual DDD tiene al menos un sesgo, es una opción arquitectónica. Ya no es una forma de pensar; Ya es algo que se te está prestando, con la mayoría de las veces advertencias demasiado vagas para ser de alguna utilidad: "no es adecuado para todo" y ".

Pero decidir ir a la manera PI o no es un desafío en sí mismo, y no puedes llamar a alguien (" codificador ") si se siente incómodo al respecto.

Tome un paquete de ERP con una interfaz similar a MS Access: cuadrículas con totales acumulados, columnas de actualización automática y desplazamiento sin páginas en 100 000 registros. Claramente, un enfoque DDD es adecuado para pensar en cómo utilizar esta aplicación. Pero en años nunca he visto a nadie, ni en libros ni en línea, a través de evidencias respaldadas por explicaciones, por no hablar de ejemplos de códigos de la vida real, de cómo PI podría lidiar con esta situación ubicua para cualquiera que quiera cumplir < fuerte> aplicaciones de grado comercial y experiencias de usuario .

No quiero ser religioso en esto. Los defensores de DDD y DAL tienden a ser excesivamente religiosos y pueden ahuyentar a aquellos que han sido mordidos una vez, pero que tienen una mentalidad abierta. Muchos solo quieren confrontar las experiencias de la vida real (es decir, PENSAR), y no ser atendidos solo con gatos, automóviles y artículos básicos de órdenes y pedidos (es decir, un CÓDIGO deficiente) para apoyar la predicación.

Answer 4

Aquí hay una pregunta muy similar: ¿Permite que el nivel web acceda directamente al DAL?

Uso DDD para todos mis proyectos. En las aplicaciones más pequeñas, algunos de los conceptos no se aplican, pero creo que muchos de los aspectos son aplicables en todos los proyectos, independientemente de su tamaño.

Answer 5

DDD es un software que se mantendrá durante un tiempo. Para mí, esto significa que necesita expresar ideas que cambiarán con el dominio. Claro que una aplicación simple puede ser perfecta para un tiempo de entrega corto y un tiempo de implementación corto. Sin embargo, si necesita hacer crecer el software, los principios DDD serán de gran ayuda. El DDD puede ser difícil desde el principio, pero una vez que tenga la idea del lenguaje ubicuo y los problemas de separación, las cosas empezarán a ser fáciles.

Answer 6

Si lees el artículo un poco más, verás esto:

  

Para el 5% de las aplicaciones donde DDD   es un buen ajuste, es un muy buen ajuste.   Para esas situaciones, DDD ayudará.   se quiebra una tuerca muy dura. Aquí, DDD   puede ser la bala de plata para eso   hombre lobo que su gerente solo   señaló a su escritorio.

Es por eso que tanto alboroto al respecto.

Answer 7

• Como su aplicación se centra principalmente en datos, quizás su arquitectura podría ser principalmente convencional.

• Para los aspectos donde tiene más lógica y posibles objetos de dominio u valor, quizás pueda aprovechar algunas de las ideas de DDD para organizar el código.

• En general, la "alternativa de sonido" es mantener las cosas lo más simple posible, usar los conceptos DDD cuando sean útiles y no complicar las cosas innecesariamente, como aconseja el artículo.

Estoy comenzando un proyecto similar ahora, es una mezcla de manipulación de datos y más áreas impulsadas por lógica / algoritmo. De manera similar, me gustaría tomar las partes de DDD que beneficiarán al proyecto, pero no intentar forzarlo en áreas donde pueda ser contraproducente.