2012-08-06 14 views
7

Una reacción común que veo en muchas preguntas hechas aquí y en otros foros es como "No es necesario hacer DDD para eso. Es una aplicación CRUD simple, DDD es una sobreingeniería".¿DDD es adecuado para todo tipo de aplicaciones?

Bueno, soy nuevo en DDD y creo que hay muchos elementos en DDD que tienen un atractivo universal y se pueden usar en general, independientemente de si su aplicación es compleja o no. Por ejemplo, capas de aplicaciones, diferentes artefactos que DDD reconoce, etc. Puede comenzar con los conceptos básicos y los modelos ciertamente anémicos y luego trabajar/refactorizar hacia la mayor pureza que uno pueda obtener.

¿Este enfoque suena bien?
¿O diría usted que hay una elección fundamental en el diseño de cada aplicación en cuanto a si se va a DDD o no, tipo de opción de "todo o nada"?

ACTUALIZACIÓN(para proporcionar más contexto, en respuesta a Hugh comentario más abajo)
  Estoy construyendo una aplicación web en torno a un tipo existente RuleEngine de aplicación, básicamente CRUD y algunas validaciones, invariantes y luego un proceso de de despliegue. La verificación de creación de reglas y semántica se realiza mediante una pieza de código independiente que llamo parte de CRUD y no existe ninguna lógica semántica específica en mi código. Estoy tratando de usar DDD para esta aplicación, pero veo que podría no ser lo suficientemente complicado para encajar en el paradigma DDD. No existe un lenguaje ubicuo definido para el dominio, es decir, el idioma no es lo suficientemente especializado como para nombrar el conjunto de entidades involucradas. Escucho que mi experto de dominio habla en términos de creación, edición y eliminación de entidades.

+2

Es poco probable que su pregunta genere muchas respuestas, ya que no se enfrenta realmente a un desafío específico sino que intenta iniciar un debate general sobre la idoneidad de un enfoque determinado, cuya respuesta suele ser "depende". –

+1

gracias hugh! para el comentario puntual y downvote, mire la actualización anterior, intenté agregar algo de contexto, con suerte esto lo ayudará a pasar el punto "depende" :). – redzedi

+0

Yo no era el infractor en este caso. +1 para proporcionar más detalles. –

Respuesta

5

DDD no es todo-o-nada. Además, muchos de los patrones descritos en DDD no son nuevos y se pueden encontrar por todos lados. Eric Evans (el autor del libro DDD) simplemente los reunió, los formalizó donde fue necesario y los relacionó entre sí. Usted es libre de usar lo que se ajuste a su espacio problemático.

Lo que a menudo se pasa por alto: DDD describe los patrones de implementación, así como los patrones de análisis. Los patrones de análisis pueden ser excesivos en muchas aplicaciones (si no la mayoría), pero los patrones de implementación (es decir, Entidades, Especificaciones, Servicios) pueden ser de gran utilidad también en escenarios menos complejos.

2

En resumen,

Si es sólo un mantenimiento, no me molestaría.

Por otro lado,

Si se tiene un comportamiento, donde el siguiente estado de algo se basa en el estado anterior, a continuación, DDD es algo que probablemente desee considerar.

Cuestiones relacionadas