Primeiro, quero dizer que essa parece ser uma pergunta / área negligenciada; portanto, se essa pergunta precisar ser aprimorada, ajude-me a fazer desta uma ótima pergunta que possa beneficiar outras pessoas! Estou procurando conselhos e ajuda de pessoas que implementaram soluções que resolvem esse problema, não apenas idéias para tentar.
Na minha experiência, existem dois lados de um aplicativo - o lado "tarefa", que é amplamente orientado por domínio e é onde os usuários interagem amplamente com o modelo de domínio (o "mecanismo" do aplicativo) e o lado de relatório, onde os usuários obtenha dados com base no que acontece no lado da tarefa.
No lado da tarefa, fica claro que um aplicativo com um modelo de domínio avançado deve ter lógica de negócios no modelo de domínio e o banco de dados deve ser usado principalmente para persistência. Separação de preocupações, todo livro é escrito sobre isso, sabemos o que fazer, incrível.
E o lado dos relatórios? Os data warehouses são aceitáveis ou são de design ruim porque incorporam a lógica de negócios no banco de dados e nos próprios dados? Para agregar os dados do banco de dados nos dados do data warehouse, você deve ter aplicado a lógica e as regras de negócios aos dados, e essa lógica e as regras não vieram do seu modelo de domínio, vieram dos seus processos de agregação de dados. Isso está errado?
Trabalho em grandes aplicações financeiras e de gerenciamento de projetos, onde a lógica de negócios é extensa. Ao relatar esses dados, muitas vezes terei MUITAS agregações para extrair as informações necessárias para o relatório / painel, e as agregações possuem muita lógica de negócios. Por uma questão de desempenho, tenho feito isso com tabelas e procedimentos armazenados altamente agregados.
Como exemplo, digamos que um relatório / painel seja necessário para mostrar uma lista de projetos ativos (imagine 10.000 projetos). Cada projeto precisará de um conjunto de métricas mostradas, por exemplo:
- orçamento total
- esforço até hoje
- taxa de queimadura
- data de esgotamento do orçamento na taxa de queima atual
- etc.
Cada um deles envolve muita lógica de negócios. E não estou falando apenas de multiplicar números ou de alguma lógica simples. Estou falando de, para obter o orçamento, você deve aplicar uma tabela de preços com 500 taxas diferentes, uma para o tempo de cada funcionário (em alguns projetos, outros têm um multiplicador), aplicar despesas e qualquer marcação apropriada etc. lógica é extensa. Foram necessários muitos ajustes de agregação e consulta para obter esses dados em um período de tempo razoável para o cliente.
Isso deve ser executado primeiro no domínio? E o desempenho? Mesmo com consultas SQL diretas, mal estou obtendo esses dados com rapidez suficiente para que o cliente seja exibido em um período de tempo razoável. Não consigo imaginar tentar obter esses dados para o cliente com rapidez suficiente se estiver reidratando todos esses objetos de domínio, misturando, combinando e agregando seus dados na camada do aplicativo ou tentando agregar os dados no aplicativo.
Nesses casos, parece que o SQL é bom em processar dados e por que não usá-los? Mas então você tem lógica de negócios fora do seu modelo de domínio. Qualquer alteração na lógica de negócios precisará ser alterada no modelo de domínio e nos esquemas de agregação de relatórios.
Estou realmente sem saber como projetar a parte de relatórios / painel de qualquer aplicativo com relação ao design orientado a domínio e boas práticas.
Eu adicionei a tag MVC porque MVC é o sabor do dia e estou usando-a no meu design atual, mas não consigo descobrir como os dados do relatório se encaixam nesse tipo de aplicativo.
Estou procurando qualquer ajuda nesta área - livros, padrões de design, palavras-chave para o google, artigos, qualquer coisa. Não consigo encontrar nenhuma informação sobre este tópico.
EDITAR E OUTRO EXEMPLO
Outro exemplo perfeito que encontrei hoje. O cliente deseja um relatório para a equipe de vendas do cliente. Eles querem o que parece ser uma métrica simples:
Para cada vendedor, quais são as vendas anuais até o momento?
Mas isso é complicado. Cada vendedor participou de várias oportunidades de vendas. Alguns ganharam, outros não. Em cada oportunidade de vendas, há vários vendedores aos quais é atribuída uma porcentagem de crédito para a venda, de acordo com sua função e participação. Então, agora, imagine passar pelo domínio para isso ... a quantidade de reidratação do objeto que você precisaria fazer para extrair esses dados do banco de dados para cada vendedor:
Obtenha todo o
SalesPeople->
Para cada um obtenha o seuSalesOpportunities->
Para cada um obtenha a sua porcentagem da venda e calcule o valor das Vendas
e adicione o valor total dasSalesOpportunityVendas.
E essa é uma métrica. Ou você pode escrever uma consulta SQL que pode fazer isso de maneira rápida e eficiente e ajustá-la para ser rápida.
EDIT 2 - Padrão CQRS
Eu li sobre o Padrão CQRS e, embora intrigante, até Martin Fowler diz que não foi testado. Então, como esse problema foi resolvido no passado. Isso deve ter sido enfrentado por todos em algum momento ou outro. O que é uma abordagem estabelecida ou desgastada, com um histórico de sucesso?
Editar 3 - Sistemas / Ferramentas de Relatório
Outra coisa a considerar neste contexto são as ferramentas de relatório. O Reporting Services / Crystal Reports, o Analysis Services e o Cognoscenti, etc. esperam dados do SQL / banco de dados. Eu duvido que seus dados cheguem aos seus negócios mais tarde. E, no entanto, eles e outras pessoas como eles são parte vital dos relatórios em muitos sistemas grandes. Como os dados para esses dados são manipulados adequadamente, onde existe uma lógica comercial na fonte de dados para esses sistemas e possivelmente nos próprios relatórios?
