¿Se supone que los objetos de dominio en Diseño impulsado por dominio son solo de escritura?

13

He estado leyendo sobre Diseño impulsado por dominio durante casi dos años y he estado introduciendo con cautela algunos conceptos en mi trabajo diario o al menos haciendo planes sobre cómo hacer las cosas que hago regularmente dentro de un Diseño dirigido por dominio.

Una conclusión a la que he llegado especialmente, en respuesta a la lectura de más información sobre la Obtención de recursos y la Segregación de responsabilidad de consulta de comando (CQRS), es que quizás los objetos de dominio estén destinados a usarse solo con fines de escritura. Para ser más claros, parece que lo que las personas sugieren sutilmente en gran parte de la documentación que he leído es que los objetos de dominio son responsables de realizar operaciones / cálculos centrados en el dominio, validación, y luego están allí principalmente para proporcionar un camino a la persistencia a través de La infraestructura provista dentro de una implementación del Repositorio. Aunque me gusta el hecho de que esto puede simplificar el modelo de dominio en gran medida, ya que elimina la responsabilidad de exponer el estado.

Si es correcto que los objetos del dominio se utilicen principalmente como objetos de solo escritura, entonces eso me plantea algunas preguntas que espero que alguien pueda responder.

  1. ¿Cómo se realizan las pruebas unitarias en un objeto que tiene definidores o métodos que modifican el estado de un objeto pero que no proporcionan una interfaz pública externa para leer el estado de los captadores de propiedades en C #? ¿Está bien exponer el estado únicamente con el propósito de hacer que ese objeto sea verificable?
  2. ¿Cómo se le muestra a un usuario los resultados de los cálculos u operaciones realizadas en el dominio sin tener que persistir y luego extraer los resultados del almacén de persistencia fuera del contexto del dominio? ¿Está bien exponer el estado únicamente con el propósito de mostrar resultados?

¿La regla general es que los únicos que obtienen propiedades (obtener accesores) deben ser los que también se pueden escribir en el dominio? ¿O dicho de otra manera, las propiedades de solo lectura deberían ser lo único que se debe evitar, ya que solo están ahí para fines de lectura y, por lo tanto, no desempeñan un papel necesario en el modelo de dominio real?

Material relacionado:

  1. TDD, DDD y encapsulación
pregunta jpierson 16.12.2011 - 06:28

3 respuestas

9

No estoy seguro de que exista una respuesta de 'una forma verdadera' para un enfoque de diseño que, para ser justos, aún esté en evolución. Primero, DDD y CQRS no son lo mismo, aunque la gente de CQRS parece haberse derivado de un punto de partida influenciado por DDD.

Hay mucho en la mentalidad de DDD y gran parte tiene que ver con los límites de problemas correctamente definidos, la comunicación entre las partes interesadas y la interacción entre los sistemas, no necesariamente una implementación específica en el código, por lo que no creo que sea demasiado duro es una virtud.

Tal vez esté viendo algo del debate sobre si los objetos de dominio deberían ser modificables, y qué función cumple un objeto de dominio en un sistema en su conjunto. CQRS divide un sistema en vías de lectura y escritura, por lo que es sensato llegar a la conclusión de que realmente no necesita acceso de lectura cuando se encuentra en la vía de escritura. Luego, la lectura se convierte en algo que usted hace contra los eventos provocados por algunos objetos de dominio y consumidos (manejados) por otros. Si retrocede un poco en el historial de CQRS, encontrará argumentos de que los objetos del dominio no deberían tener definidores, solo captadores y un solo método de "controlador". La lógica aquí es que solo los eventos que consumen pueden dar como resultado un cambio de estado, y ese cambio se maneja por completo internamente por el objeto de dominio.

Usted muestra los resultados del cambio tratándolos como artefactos de cambio separados, colocándolos en una estructura separada y plana (por ejemplo, una tabla) y leyéndolo como si solo estuviera leyendo un informe sobre el estado actual e histórico del sistema. Por ejemplo, podría consumir un evento extrayendo los datos que necesita para leerlos y guardándolos en una tabla de base de datos que se asigna estrechamente a una vista única (por ejemplo, una pantalla) de su sistema.

Si experimenta con este estilo, tenga en cuenta que es probable que otros programadores no estén familiarizados con este enfoque, y que existen relativamente pocos escenarios (pero interesantes) donde es justificable como un enfoque de diseño.

Para las pruebas unitarias, hay un par de enfoques que pueden funcionar para usted. La primera, y la más natural, es verificar que los eventos que espera ver provocados por los objetos de su dominio son correctos. Un objeto de dominio podría generar un evento genérico modificado que contenga información sobre el cambio. Podrías verificar eso. Se podría verificar el hecho de que el evento se planteó en absoluto y que otros eventos no se produjeron.

Otro enfoque es usar Test Spies que exponen atributos legibles en su objeto de dominio para que pueda verificar los cambios de estado. Por ejemplo, puede heredar de su objeto de dominio, agregar algunos accesores para leer el estado encapsulado de lo contrario y verificar que sea correcto.

Una vez más, estás confundido porque estos enfoques son confusos. Si está buscando adoptar algunas buenas ideas en su programación, tome los bits jugosos primero. Los límites de DDD y hacer que los roles sean explícitos son cambios en su forma de pensar acerca de la comunicación con su código. Como mínimo, CQRS sugiere que la lectura de datos y la escritura de datos son operaciones segregables. Esa información lo lleva a pensar muy claramente acerca de cuál es el rol de los datos que debe presentar, cuánto necesita realmente, quién los consume, qué tan reciente debe ser, etc. No necesita una Implementación completa de Event Sourcing para adoptar una mejor encapsulación en su codificación. Puede comenzar simplemente enfocándose en las operaciones atómicas dentro de su objeto, los enfoques "Decir, no preguntar" para el diseño de la interfaz del objeto y la Inversión de control a través de eventos / manejadores en lugar de un control estricto dentro de los servicios de procedimientos.

    
respondido por el pfries 15.03.2012 - 17:29
1
  

¿Se supone que los objetos de dominio en Diseño impulsado por dominio solo deben ser   solo escritura?

No. CQRS puede usarse junto con DDD.

    
respondido por el NimChimpsky 14.02.2012 - 11:32
0

Las pruebas unitarias de su modelo de dominio deben estar verificando que para cada comando ejecutado se generan los eventos de dominio correctos. Los comandos de su dominio y los eventos capturados pueden ser interrogados por estado.

También puede anular ToString() en los comandos y eventos de su dominio para proporcionar informes de estado automáticos y legibles por humanos.

Para responder a su segunda pregunta, para mostrar los resultados de los comandos, debe organizar que los eventos de dominio se 'publiquen' en su modelo de lectura.

    
respondido por el Ed James 16.12.2011 - 10:21

Lea otras preguntas en las etiquetas