oop - ¿DDD es una pérdida de tiempo?
domain-driven-design (7)
Google "¿Para qué tipo de aplicaciones es adecuada DDD?" me dio la siguiente respuesta:
Probablemente, el 95% de todas las aplicaciones de software entran en las categorías "no tan bueno para usar DDD". (ver el artículo )
Entonces, ¿qué es todo el alboroto?!?
La aplicación en la que estoy trabajando está principalmente centrada en los datos, pero aún contiene algunas reglas y lógica de negocios para aplicar. ¿Sería una pérdida de tiempo comenzar a aplicar técnicas de DDD? ¿Me conviene usar 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 manera diferente: ¿qué es una alternativa sonora a DDD?
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 considero que muchos de los aspectos son aplicables en todos los proyectos, independientemente del tamaño.
DDD es sobre software que se mantendrá por 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 por un corto tiempo de entrega y corto tiempo de implementación. Sin embargo, si necesita hacer crecer el software, los principios de DDD le serán de gran ayuda. DDD puede ser difícil desde el principio, pero una vez que tenga la idea del lenguaje omnipresente y las preocupaciones sobre la separación, las cosas empezarán a ser más fáciles.
Lo siento, pero si DDD fuera solo una forma de pensar como dice Frans Bouma, entonces no recomendaría cosas tales como Persistence Ignorance. Esto está descartando a otros como desarrolladores algo subclase.
PI, para el cual DDD tiene al menos un sesgo, es una elección arquitectónica. Ya no es una forma de pensar; ya es algo que se te está sirviendo, con la mayoría de las veces demasiadas advertencias vagas para ser de alguna utilidad: "no apto para todo".
Pero decidir seguir o no la PI es un desafío en sí mismo, y no se puede llamar a alguien ("codificador") si se siente incómodo con esto.
Tome un paquete ERP con una interfaz similar a MS Access: cuadrículas con totales acumulados, columnas de actualización automática y desplazamiento sin página en 100 000 registros. Claramente, un enfoque DDD es adecuado para pensar en cómo hacer esta aplicación. Pero en años nunca he visto a nadie, ni en libros ni en línea, recurriendo a explicaciones respaldadas por evidencia, y menos ejemplos de códigos de la vida real, de cómo PI podría lidiar con esta situación omnipresente para cualquiera que desee ofrecer aplicaciones comerciales y experiencias de usuario .
No quiero ser religioso en esto. Los proponentes de DDD y DAL tienden a ser excesivamente religiosos y pueden ahuyentar a aquellos que han sido mordidos una vez pero que son / fueron de mente abierta. Muchos solo quieren confrontar experiencias de la vida real (es decir, PIENSO), y no recibir el servicio solo con Gatos, Automóviles, y Órdenes / Pedidos básicos (es decir, CÓDIGO pobre) para apoyar la predicación.
Muchos desarrolladores que piensan que DDD es útil para su proyecto caen en la trampa de que creen que su trabajo consiste en escribir código. Este no es el caso. El trabajo de un desarrollador consiste en realizar funcionalidades para que un problema pueda resolverse a través del software. Esto lleva a la conclusión de que escribir código no es el comienzo 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 se escriba realmente.
DDD no se trata de escribir código, no es un proceso de 10 pasos clave para obtener un excelente software, se trata de todo el proceso ANTES de que se escriba el código, se trata de obtener información sobre de qué se trata el problema, qué / quién participa en qué flujo de información y qué aspecto tienen 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 de dominio y desarrolladores sin malas interpretaciones . Esta es la ''Lengua ubicua'' de la que Evans habla. De hecho, hace que todo el proceso ANTES de escribir el código sea un proceso que deja poco que adivinar, las cosas son claras y directas. (ese es el objetivo).
El problema con ''¿cómo funciona DDD en la práctica'' y ''podría alguien darme un ejemplo de cómo escribo código con DDD?'' y cosas por el estilo realmente provienen del hecho de que las personas que hacen este tipo de preguntas se enfocan en escribir código, pero no tienen idea de POR QUÉ están escribiendo ESE código y no otro código. Iow: si te das cuenta de que DDD se trata de descubrir LO QUE debes escribir como funcionalidad y POR QUÉ, las cosas encajan. CÓMO está escribiendo ese código, eso depende de usted. Pero como dije: ese no es el mayor problema, ya que para entonces ya sabes lo que tienes que escribir y por qué.
Si lees el artículo un poco más, verás esto:
Para el 5% de las aplicaciones donde DDD es una buena opción, es una muy buena opción. Para esas situaciones, DDD te ayudará a romper una nuez muy dura. Aquí, DDD puede ser la bala de plata para ese hombre lobo que su gerente acaba de señalar a su escritorio.
Es por eso que el alboroto al respecto.
ya sabes, a veces el 5% gana más dinero que el otro 95%, por eso DDD existe.
es para un sistema grande complejo específico.
Como su aplicación se centra principalmente en datos, tal vez su arquitectura podría ser principalmente convencional.
Para los aspectos en los que tiene más lógica y posibles objetos de dominio u objetos de valor, tal vez podría 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 simples posible, usar los conceptos de DDD cuando sea útil y no complicar innecesariamente las cosas, como lo indica 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 el proyecto, pero no intentar forzarlo en áreas donde puede ser contraproducente.