Primero, quiero decir que esta parece ser una pregunta / área descuidada, así que si esta pregunta necesita mejorar, ¡ayúdame a hacer de esta una gran pregunta que pueda beneficiar a otros! Estoy buscando consejos y ayuda de personas que han implementado soluciones que resuelven este problema, no solo ideas para probar.
En mi experiencia, hay dos lados de una aplicación: el lado de "tarea", que es en gran medida impulsado por el dominio y es donde los usuarios interactúan ricamente con el modelo de dominio (el "motor" de la aplicación) y el lado de los informes, donde los usuarios obtener datos basados en lo que sucede en el lado de la tarea.
Por el lado de la tarea, está claro que una aplicación con un modelo de dominio rico debería tener lógica de negocios en el modelo de dominio y la base de datos debería usarse principalmente para persistencia. Separación de preocupaciones, cada libro está escrito al respecto, sabemos qué hacer, increíble.
¿Qué pasa con el lado de los informes? ¿Son aceptables los almacenes de datos o tienen un diseño incorrecto porque incorporan la lógica empresarial en la base de datos y en los mismos datos? Para agregar los datos de la base de datos a los datos del almacén de datos, debe haber aplicado lógica y reglas de negocio a los datos, y esa lógica y reglas no provienen de su modelo de dominio, sino de sus procesos de agregación de datos. ¿Es eso incorrecto?
Trabajo en grandes aplicaciones financieras y de gestión de proyectos donde la lógica de negocios es extensa. Al informar sobre estos datos, a menudo tendré que hacer MUCHAS agregaciones para extraer la información requerida para el informe / tablero, y las agregaciones tienen mucha lógica comercial. Por razones de rendimiento, lo he estado haciendo con tablas altamente agregadas y procedimientos almacenados.
Como ejemplo, supongamos que se necesita un informe / tablero para mostrar una lista de proyectos activos (imagine 10,000 proyectos). Cada proyecto necesitará un conjunto de métricas que se muestran con él, por ejemplo:
- presupuesto total
- esfuerzo hasta la fecha
- velocidad de combustión
- fecha de agotamiento del presupuesto a la tasa de quemado actual
- etc.
Cada uno de estos implica mucha lógica de negocios. Y no solo estoy hablando de multiplicar números o alguna lógica simple. Estoy hablando para obtener el presupuesto, debe aplicar una hoja de tarifas con 500 tarifas diferentes, una para el tiempo de cada empleado (en algunos proyectos, otros tienen un multiplicador), aplicar los gastos y cualquier margen de beneficio apropiado, etc. La lógica es extensa. Tomó mucha agregación y ajuste de consultas para obtener estos datos en un tiempo razonable para el cliente.
¿Debería esto ejecutarse primero a través del dominio? ¿Qué pasa con el rendimiento? Incluso con consultas SQL directas, apenas obtengo estos datos lo suficientemente rápido como para que el cliente los muestre en un período de tiempo razonable. No puedo imaginar tratar de llevar estos datos al cliente lo suficientemente rápido si estoy rehidratando todos estos objetos de dominio, y mezclando y combinando y agregando sus datos en la capa de la aplicación, o tratando de agregar los datos en la aplicación.
Parece en estos casos que SQL es bueno para procesar datos, y ¿por qué no usarlo? Pero entonces tienes lógica de negocios fuera de tu modelo de dominio. Cualquier cambio en la lógica de negocios deberá cambiarse en su modelo de dominio y en sus esquemas de agregación de informes.
Realmente no sé cómo diseñar la parte de informes / tablero de cualquier aplicación con respecto al diseño impulsado por el dominio y las buenas prácticas.
Agregué la etiqueta MVC porque MVC es el sabor del diseño del día y la estoy usando en mi diseño actual, pero no puedo entender cómo encajan los datos de informes en este tipo de aplicación.
Estoy buscando ayuda en esta área: libros, patrones de diseño, palabras clave para google, artículos, cualquier cosa. No puedo encontrar ninguna información sobre este tema.
EDITAR Y OTRO EJEMPLO
Otro ejemplo perfecto que encontré hoy. El cliente quiere un informe para el equipo de ventas del cliente. Quieren lo que parece una métrica simple:
Para cada persona de ventas, ¿cuáles son sus ventas anuales hasta la fecha?
Pero eso es complicado. Cada vendedor participó en múltiples oportunidades de ventas. Algunos ganaron, otros no. En cada oportunidad de ventas, hay varias personas de ventas a las que se les asigna un porcentaje de crédito para la venta por su función y participación. Así que ahora imagine pasar por el dominio para esto ... la cantidad de rehidratación de objetos que tendría que hacer para extraer estos datos de la base de datos para cada vendedor:
Obtenga todos los
SalesPeople->
Para cada uno obtenga suSalesOpportunities->
Para cada uno obtenga su porcentaje de la venta y calcule su Monto de ventas y
luego sume todos susSalesOpportunityMontos de ventas.
Y esa es UNA métrica. O puede escribir una consulta SQL que pueda hacerlo de manera rápida y eficiente y ajustarla para que sea rápida.
EDIT 2 - Patrón CQRS
He leído sobre el patrón CQRS y, aunque es intrigante, incluso Martin Fowler dice que no se ha probado. Entonces, ¿cómo se resolvió este problema en el pasado? Esto debe haber sido enfrentado por todos en algún momento u otro. ¿Qué es un enfoque establecido o bien usado con un historial de éxito?
Edición 3 - Sistemas / herramientas de informes
Otra cosa a considerar en este contexto son las herramientas de informes. Reporting Services / Crystal Reports, Analysis Services y Cognoscenti, etc., todos esperan datos de SQL / base de datos. Dudo que sus datos lleguen a través de su negocio más tarde para estos. Y, sin embargo, ellos y otros como ellos son una parte vital de los informes en muchos sistemas grandes. ¿Cómo se manejan adecuadamente los datos para estos cuando hay incluso lógica de negocios en la fuente de datos para estos sistemas, así como posiblemente en los propios informes?
