¿Cómo maneja Domain Namen Design Reporting?

Question

Encontré DDD siendo natural si estoy trabajando en un tipo de aplicación operacional/transaccional. Sin embargo, siempre estoy sorprendido de una manera razonable para manejar el tipo de informe de funciones.

Los informes en los que estoy hablando no están obligados a informar generación, sino también funciones que realizan consultas comparativamente complicadas. (por ejemplo, dando el resumen de todos los pedidos que hizo un comerciante, o muestra el resumen de la cuenta para cuentas comerciales que tienen ciertas acciones, etc.). Pueden ser simplemente algunas consultas o funciones de apoyo que se utilizan junto con esas funciones operativas.

Para estas funciones, es bastante natural si podemos realizar join en SQL (o en cualquier lenguaje de consulta), obtener las columnas que nos interesen y devolver el conjunto de resultados del masaje. Sin embargo, parece que no funciona tan bien con DDD: necesitamos un repositorio especial adicional o tener un repositorio más relacionado existente que devuelva un "objeto de entidad/valor" especial (que es el conjunto de resultados especializado). Este tipo de "entidades" especiales no tiene ningún significado de dominio de hecho.

Si queremos hacer uso de la capa de dominio significativa, eso puede crear muchas búsquedas extra de diferentes repositorios, además de una gran cantidad de trabajo de agregación en el dominio o capa de servicio, que fácilmente causará degradación de rendimiento horrible.

También he pensado tener otra "ruta" para este tipo de función, que no pasa por la "ruta DDD", que tiene su propia forma de obtener los datos del informe de DB, compone los resultados para mostrar. Sin embargo, hará que la aplicación sea innecesariamente complicada, y lo que es peor, proporcionamos una ruta adicional para que los desarrolladores más acostumbrados al desarrollo tradicional orientado a bases de datos tiendan a utilizar esta ruta, incluso si no es apropiado.

Pensé que tal situación es bastante común (normalmente un gran sistema no contendrá funciones operativas sino de informes y consultas), ¿me gustaría saber cómo lo están tratando las personas?

Answer 1

Recientemente comenzamos a usar DDD para el desarrollo del sistema. Tenía las mismas preocupaciones que la suya, pero finalmente me conformé con la segregación de responsabilidad de consulta de comando (CQRS) [Fowler, Young, Dahan]. Si bien se requiere "la ruta db" para consultar, no siento en absoluto que sea tentador enviar directamente a DB los Comandos (los que alteran el estado del dominio). La separación es muy clara: los comandos pasan por el dominio, las consultas van directamente a DB.

Answer 2

Un enfoque sería tener un sistema de informes por separado que ejecutara los datos del almacén de datos de su aplicación para almacenar otra copia de los datos en un formato más relacional.

Un atajo que he usado es crear una vista o un procedimiento almacenado para devolver los datos unidos en un simple objeto tonto.

Answer 3

consultas comparativamente complicadas. (por ejemplo, dando el resumen de todas las órdenes que hizo un operador, o muestra el resumen de la cuenta para cuentas comerciales que tienen ciertas existencias, etc.)

Es común que los repositorios realicen tales tareas. Creo que le preocupa cómo implementar esto de manera eficiente, y la respuesta a eso es "carga lenta".

Por ejemplo, tomemos el "resumen de todos los pedidos que hizo un comerciante". El "resumen" es una tarea de informe, así que dejemos eso de lado. La tarea del dominio es "encontrar todas las órdenes para un comerciante". Es posible que tenga un método de depósito de la siguiente manera:

List<Order> findOrdersByTrader(Trader trader); 

se puede implementar esta cargando sólo la información mínima expresión (Resumen) para cada orden. Si luego se inyecta la interfaz del repositorio en la entidad Order, la propia entidad puede solicitar al repositorio que cargue sub-entidades adicionales cuando sea necesario.

---

Actualización: Su comentario hace que el problema más claro - no he entendido bien la parte anterior de agregación. Parece que el "resumen de orden" realmente pertenece a su dominio en ese momento. A veces no es obvio que un concepto sea parte del dominio, pero si es una característica de la que los usuarios hablan ("Quiero ver un resumen de los pedidos realizados por este comerciante") y no hay un objeto existente que pueda hacer esto. , eso es un signo de un concepto oculto en tu dominio. Después de todo, necesita algún objeto para realizar un seguimiento de "cuántos pedidos hay por cada stock" y no hay motivo para que este objeto no pueda formar parte de su dominio.

Answer 4

En términos de informes DDD en la mayoría de los casos es un contexto delimitado por separado y un subdominio de apoyo donde el diseño impulsado por el dominio sería excesivo. Recuerde el concepto más importante de DDD: enfoque sus esfuerzos de modelado en el dominio principal e implemente todo lo demás utilizando la solución más simple posible.