design-patterns - patterns - proxy pattern
Metodología de diseño: caso de uso manejado vs. dominio manejado (6)
El diseño impulsado por el dominio esencialmente trata de actuar como si conocieras de antemano todos los posibles casos de uso. Por definición, el dominio "problema" es el conjunto de problemas específicos que se consideran miembros de ese dominio.
Solo para discusión, para mí parece que 2 terminologías diferentes en realidad están diciendo lo mismo. ¿Hay alguna diferencia tangible entre estos 2 enfoques de diseño?
Esta es mi interpretación personal basada en la experiencia.
El diseño basado en casos de uso utiliza el caso de uso como una herramienta para descubrir la entidad, la interfaz, el mensaje de interacción y el flujo de trabajo sobre cómo se están llevando a cabo ciertas operaciones comerciales. Esto se usa a menudo en más etapas de análisis o diseño para recopilar o comprender los requisitos y establecer algunos diseños iniciales. Por otro lado, DDD está más orientado hacia la implementación con un fuerte enfoque en la entidad de dominio y el contexto. Se enfoca en más detalles que el caso de uso en términos de definir el modelo (como clases, interfaces) y definir sus límites, agregaciones, operaciones y lógica específica del dominio. En general, sigue alguna práctica estándar sobre cómo abordarlos en la implementación.
DDD es más adecuado cuando se trata de un proyecto que se dirige a un dominio específico, como contabilidad, ingeniería, donde se puede prever que algunos o la mayoría de los modelos de la empresa pueden tener una interrelación compleja y una lógica incorporada. La elección entre el diseño basado en casos de uso o DDD también depende de la disponibilidad de los expertos en dominios. Si tiene partes interesadas con necesidades comerciales (solo un poco de acceso a los expertos en dominios), entonces el diseño basado en casos de uso es más adecuado si se compara con DDD. Es alto riesgo adoptar DDD si no tiene expertos en dominios que participan directamente en el desarrollo de el proyecto.
Personalmente, creo que ambos pueden complementarse entre sí en algunos proyectos donde puede comenzar con el diseño basado en casos de uso y abordar el diseño detallado y la implementación utilizando el enfoque DDD.
No soy un experto en esto, y estos términos pueden ser difusos, y significan cosas diferentes para diferentes personas. Pero..
Habría dicho que en un Diseño de Dominio había un sistema existente (en papel, manual, lo que fuera) y el software modela las entidades reales en el sistema. Entonces, en un sistema de bibliotecas, miras una biblioteca y ves que hay libros, estanterías, armarios y habitaciones. Y en base a eso modelas el dominio real en el software.
Con el caso de uso, usted comienza con ''¿qué estamos tratando de hacer?'' Puede ser que no necesite habitaciones diferentes en su modelo, porque no son necesarias en los casos de uso. Eso hace que su sistema sea más simple (y menos propenso a errores), pero si no está modelando el "mundo real", perderá algo de flexibilidad.
El enfoque basado en casos de uso funciona bien si solo tiene un cliente para el producto y el cliente ya le ha informado sobre todos los problemas que deben resolverse por producto. Esto es posible en empresas orientadas al servicio en general. Se vuelve difícil de administrar cuando tiene varios clientes para el mismo Producto. Esto sucede generalmente en las empresas de desarrollo de productos. En tales casos (Product Driven Companies) DDD es útil. Desarrolla un producto utilizando DDD (lo llama como base). Luego, verifique si todos los casos de uso para el nuevo cliente son aplicables, de lo contrario, formen una capa sobre la base para los cambios específicos del cliente.
Los casos de uso se centran en los usuarios, las acciones y los procesos . Esto es excelente desde una perspectiva comercial, porque todos pueden ver una vista abstracta de lo que proporcionará el sistema.
DDD se enfoca en crear software que resuelva problemas. El '' ¿Quién puede resolver esto? ''y el'' ¿Qué proceso seguirán? ''ven después.
DDD realmente llega a los problemas centrales anteriormente en el proceso de diseño y lo ayuda a estructurar su solución (es decir, identificar entidades, objetos de valor, repositorios, servicios de dominio / aplicación / infraestructura, contextos limitados, especificaciones, etc. ).
Los casos de uso no cubren esto en absoluto, o cómo administrar su desarrollo ( capas anticorrupción, formas separadas, etc. )
En mi experiencia, DDD ofrece más flexibilidad (¿cambiando los requisitos de alguien?) Y proporciona las bases para sus casos de uso. Una vez que haya implementado su Modelo de Dominio , los Casos de Uso se pueden implementar utilizando Controladores / Motores de flujo de trabajo / UI que se conectan con su Modelo de Dominio. Muy a menudo, he identificado brechas en los requisitos de negocios simplemente al crear modelos de dominio.
Y habiendo asistido a una charla de Ivar Jacobsen hace algunos años, también diría que el DDD se adapta mejor a Agile.
Para mí, el Diseño Dirigido por Dominio (DDD) es más "todo en compilación"; donde los casos de uso son solo una herramienta que se enfoca en una vista específica: cómo un algo responde al estímulo y se utiliza para capturar o documentar los requisitos de comportamiento.
Para mí, el término "dominio" es uno cargado: infiere una visión más amplia de todos los conceptos relevantes para un área de problema específica.
Al describir cómo interactúan las partes del dominio, específicamente cómo responden a los estímulos, puede usar Casos de uso.
En lo que respecta a un enfoque: los casos de uso son la vista "adicional" en el Modelo de vista arquitectónica 4 + 1 , pero no son un enfoque de diseño por sí solos.
Otra distinción es que la DDD a menudo está muy vinculada a un modelo o sistema orientado a objetos; De esta manera, DDD captura / representa (entre otras cosas) la estructura de un sistema, algo que los Casos de Uso no hacen.