En Diseño impulsado por dominio, ¿puede usar las entidades de su dominio en su UI?

Question

En muchos proyectos líderes de DDD, especialmente en el estilo MVC, veo la UI usando objetos de visualización que reflejan entidades de dominio, en lugar de usar esos objetos de dominio directamente. Este estilo es obviamente para el desacoplamiento y la separación de las preocupaciones, y yo personalmente prefiero este estilo.

Pero de lo que no estoy seguro es si este es un principio estricto de DDD, o si esto es más simplemente la interpretación de diferentes desarrolladores de la misma.

¿Puede utilizar sus objetos de dominio directamente en la interfaz de usuario, y aún seguir la metodología DDD en esa ley?

¿O es una mejor práctica de DDD usar siempre objetos de visualización?

Nota: Aunque menciono MVC, estoy realmente interesado en si los objetos de visualización deben usarse en casi todos los patrones de UI compatibles con DDD en un proyecto DDD.

Answer 1

DDD es una forma de pensar al diseñar un software que comienza con el modelado del dominio. A medida que el webpage pone:

Diseño guiado por el dominio no es una tecnología o una metodología. Es una forma de pensar y un conjunto de prioridades , destinadas a acelerar los proyectos de software que tienen que ocuparse de con dominios complicados.

Una cosa que se sigue naturalmente de este patrón de diseño es una arquitectura en capas. Como se dice en DDD Pattern Summaries

partición de un programa complejo en capas. Desarrolle un diseño dentro de cada CAPA que sea coherente y que dependa solo de las siguientes capas. Siga los patrones arquitectónicos estándar para proporcionar un acoplamiento flojo a las capas de arriba. Concentre todo el código relacionado con el modelo de dominio en una capa y aíslela de la interfaz del usuario, la aplicación y el código de la infraestructura . Los objetos de dominio , sin la responsabilidad de que se muestran a sí mismos, que almacenan ellos mismos, administran las tareas de la aplicación , y así sucesivamente, pueden centrarse en expresando el modelo de dominio.Este permite que un modelo evolucione para ser rico suficiente y lo suficientemente claro como para capturar conocimientos esenciales del negocio y poner en funcionamiento.

Si necesita tener objetos de visualización para hacer eso? Esa es solo una forma de implementar esto, pero tal vez ni siquiera sea la mejor opción para proporcionar un acoplamiento flexible. Como un ejemplo: tal vez la capa de vista no es más que un navegador web y xlt archivos para visualizar archivos xml emitidos por la capa de negocios? Si alguien tiene más ejemplos adecuados, agrégalos. Mi punto es que DDD enfatiza una arquitectura en capas, pero no limita esto a una posible solución.

Answer 2

Si está haciendo un patrón MVC, necesita ver objetos; el DDD es solo tu modelo Eso no significa que usted debe siempre use MVC; un DDD podría construirse, por ejemplo, como un simulador, donde todo lo que miras son los mensajes de registro emitidos. Pero en MVC realmente deberías tener objetos de vista separados.

Ahora, pregúntese por qué sería eso? La respuesta es que la vista puede cambiar, aunque el modelo de negocio no contiene. El modelo DDD debe expresar, en términos comerciales, lo que es esencial para el negocio.

Answer 3

Dentro de un diseño MVC normalmente tendrías una asignación desde Repository -> Domain Models y luego desde Domain Models -> View Models. Los modelos de vista a menudo contienen objetos de dominio.

Answer 4

La respuesta es bastante sencillo:

• El dominio objetos tienen diseño y métodos orientados dominio.
• Los objetos de vista tienen diseño y métodos orientados a la vista/control.

Si puede usar sus objetos de dominio en la vista, es posible que no estén orientados al dominio.

Answer 5

Realmente no comencé a entender por qué o cómo desacoplaría el modelo de dominio de las preocupaciones de presentación hasta que comencé a seguir el trabajo de Greg Young y Udi Dahan (a través de Martin Fowler).

Han estado enseñando un principio conocido como Command and Query Responsibility Segregation (CQRS).

Mi interpretación de CQRS es que hay dos tipos de responsabilidades que puede tirar de un modelo de dominio en direcciones diferentes, lo que resulta en un modelo que hace un trabajo mediocre de ambos. Las dos responsabilidades son los comandos (es decir, el comportamiento que causaría una escritura en la base de datos) y las consultas (es decir, la lectura desde la base de datos para obtener datos para el consumo de UI). Un ejemplo sería agregar getters y setters a sus entidades para admitir databinding en la UI. Si su modelo tiene getters y setters, probablemente hará un mal trabajo al modelar los cambios de estado que deben ocurrir de forma transaccional o encapsulando la lógica de negocios. Tampoco tendrá forma de modelar el contexto comercial de los cambios de estado (ver Event Sourcing).

En términos DDD, puede decir que el modelo de dominio y el modelo de presentación suelen estar en Contextos delimitados separados.

La solución según lo prescrito por CQRS es crear un modelo para los comandos y otra para consultas. Si su modelo actual tiene métodos para cambiar el estado (es decir, el comportamiento en el modelo) y captadores que exponen el estado a una interfaz de usuario para la vinculación de datos, debe refaccionar estas dos responsabilidades en modelos separados para comandos y consultas. El modelo de consulta no se asignará a las entidades de su dominio, sino que se asignará directamente a la base de datos. Si su base de datos no captura el estado derivado de su modelo de dominio, consulte un patrón llamado Eager Read Derivation.

Si el sistema es simplemente CRUD y no tiene un comportamiento, probar un sistema de andamiaje que se puede construir automáticamente de tu base de datos, como datos dinámicos de ASP.NET

Answer 6

objetos de dominio son realmente la lógica interna dentro de su capa de lógica de negocios. No deben exponerse directamente a sus clientes (capa UI). En su lugar, encapsular el uso de su modelo de dominio en los servicios de aplicaciones. Los servicios de aplicaciones pueden utilizar dtos ligeros y/o objetos de comando para pasar datos e intenciones entre el cliente y el modelo de dominio.