在域丰富的应用程序中检索报告和仪表板数据的最佳实践或设计模式

首先，我想说这似乎是一个被忽略的问题/领域，因此，如果这个问题需要改进，请帮助我将此问题变成一个有益于他人的好问题！我正在寻求实施解决方案的人员的建议和帮助，而不仅仅是尝试的想法。

根据我的经验，应用程序有两个方面-“任务”方面，这主要是域驱动的，用户可以在其中与域模型（应用程序的“引擎”）进行丰富的交互，而报告方面则是用户根据任务侧发生的情况获取数据。

在任务方面，很显然，具有丰富域模型的应用程序应在域模型中具有业务逻辑，并且数据库应主要用于持久性。分离关注点，每本书都为此而写，我们知道该怎么做，太好了。

报告方面呢？数据仓库是可以接受的，还是由于将业务逻辑合并到数据库以及数据本身而设计不当？为了将数据库中的数据聚合到数据仓库数据中，您必须对数据应用业务逻辑和规则，并且该逻辑和规则不是来自您的域模型，而是来自您的数据聚合过程。错了吗

我致力于业务逻辑广泛的大型财务和项目管理应用程序。在报告这些数据时，我经常会做很多汇总工作以提取报告/仪表盘所需的信息，并且这些汇总中有很多业务逻辑。为了提高性能，我一直在使用高度聚合的表和存储过程进行此操作。

例如，假设需要一个报告/仪表板来显示活动项目的列表（设想10,000个项目）。每个项目将需要显示一组指标，例如：

1. 总预算
2. 迄今为止的努力
3. 燃烧率
4. 以当前消耗率计算的预算用尽日期
5. 等等

这些都涉及很多业务逻辑。我不仅在谈论乘数或一些简单的逻辑。我说的是为了获得预算，您必须应用一个包含500个不同费率的费率表，每个费率适用于每个员工的时间（在某些项目中，其他项目具有乘数），应用费用和任何适当的加价等。逻辑是广泛的。为了使客户端在合理的时间内获得大量数据，需要进行大量的聚合和查询调整。

应该首先在域中运行它吗？性能如何？即使使用直接的SQL查询，我也无法获得足够快的数据以使客户端在合理的时间内显示。我无法想象如果要重新为所有这些域对象补水，并在应用程序层中混合，匹配和聚合它们的数据，或者试图在应用程序中聚合数据，那么尝试将这些数据足够快地发送到客户端。

在这些情况下，SQL似乎擅长处理数据，为什么不使用它呢？但是，那么您在域模型之外就有了业务逻辑。对业务逻辑的任何更改都必须在您的域模型和报告聚合方案中进行更改。

对于域驱动设计和良好实践，如何设计任何应用程序的报告/仪表板部分，我实在感到茫然。

我添加了MVC标签，因为MVC是jour的设计风格，并且在我当前的设计中使用了它，但无法弄清楚报告数据如何适合此类应用程序。

我正在寻找这方面的任何帮助-书籍，设计模式，谷歌关键字，文章等等。我找不到有关此主题的任何信息。

编辑和另一个例子

我今天遇到的另一个完美的例子。客户需要为客户销售团队提供报告。他们想要看似简单的指标：

对于每个销售人员，他们迄今为止的年销售额是多少？

但这很复杂。每个销售人员参加了多个销售机会。有些人赢了，有些人没有。在每个销售机会中，都有多个销售人员，每个销售人员根据其角色和参与度分配一定比例的销售功劳。因此，现在想象一下要遍历该域...为每个销售人员从数据库中提取此数据所需要做的对象补液量：

获取所有SalesPeople->
对于每个获取其SalesOpportunities->
对于每个获取其销售百分比并计算其销售金额，
然后将所有SalesOpportunity销售金额相加。

这是一个指标。或者，您可以编写一个SQL查询，该查询可以快速有效地完成并对其进行快速调整。

编辑2- CQRS模式

我已经阅读了有关CQRS模式的信息，尽管很有趣，但即使是马丁·福勒（Martin Fowler）也说它未经测试。那么BEEN过去如何解决这个问题。每个人在某个时候或某些时候都必须面对这一点。具有成功记录的既定方法或陈旧方法是什么？

编辑3-报告系统/工具

在这种情况下，要考虑的另一件事是报告工具。Reporting Services / Crystal报表，Analysis Services和Cognoscenti等都希望从SQL /数据库获取数据。我怀疑您的数据稍后会通过您的业务。然而，在许多大型系统中，它们和其他类似的对象仍然是报告的重要组成部分。在这些系统的数据源甚至报告本身中甚至存在业务逻辑的地方，如何正确处理这些数据？

这是一个非常客气的答案，但是请紧贴问题的核心：

就DDD而言，您可能会认为报告是“有限的上下文”？因此，您应该愿意考虑拥有多个模型是可以的，而不是按照“ THE”域模型进行思考。因此，是的，如果报告域中包含报告业务逻辑就可以了，就像交易域中可以包含交易业务逻辑一样。

关于应用程序代码中的SQL存储过程与域模型之类的问题，报告系统与事务系统的优缺点相同。

由于我发现您为该问题添加了赏金，因此我再次阅读了该问题，并注意到您正在寻求有关此问题的特定资源，因此，我认为我首先建议您查看与此相关的其他Stack Overflow问题，我发现了这个https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

这样做的一般要旨是将CQRS用作系统的模式，这与DDD一致，并依靠查询方的责任来完成报告，但是我不确定这是否对您有帮助你的情况。

我还发现了这个http://www.martinfowler.com/bliki/ReportingDatabase.html，我发现它从这里链接：http : //groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

这是ACM关于此事的一篇有趣的文章：http : //dl.acm.org/citation.cfm?id=2064685，但它在付费专栏后面，所以我无法真正阅读（不是ACM成员:(）。

这里也有类似问题的答案：https : //stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

而这个：http : //snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

希望这可以帮助！

我对您的问题的理解是：日常任务申请

查看>>控制器>>模型（BL）>>数据库（数据）

申请呈报目的

查看>>控制器>>模型>>数据库（Data + BL）

因此，“ 任务应用程序 ” 的BL 更改也会导致“ 报告 ” BL的更改。那是你真正的问题吧？好吧，可以两次进行更改，但是无论如何，您都必须承担痛苦。原因是两个BL都由各自的关注点分开。一种用于获取数据，另一种用于汇总数据。同样，您的原始BL和聚集BL将使用不同的技术或语言（C＃/ java和SQL proc）编写。它无法逃脱。

让我们再举一个与报告无关的例子。假设公司XXX跟踪所有用户的邮件以进行解释，然后将该信息出售给营销公司。现在它将有一个BL用于解释，一个BL用于汇总营销公司的数据。这两个BL的关注点有所不同。明天，如果其BL发生更改，以致应忽略来自古巴的邮件，那么双方的业务逻辑都会发生变化。

概括地说，报告是有限的上下文或子域。它解决了收集/聚合数据并对其进行处理以获取商业智能的业务需求。

如何实现此子域可能会在（最正确的）体系结构正确方法与基础架构所允许的范围之间取得平衡。我喜欢从前者开始，仅在必要时才朝后者发展。

您可以将其分解为两个要解决的主要问题：

1. 汇总或存储数据。这应该处理一些数据源，并以将其存储在另一个数据源中的方式组合信息。

2. 查询聚合的数据源以提供商业智能。

这些问题均未引用任何特定的数据库或存储引擎。您的域层应该只处理接口，这些接口是通过各种存储适配器在基础结构层中实现的。

您可能有各种各样的工人或一些计划的工作，这些工作分为几个移动部分：

• 要查询的东西
• 聚合的东西
• 储存的东西

希望您可以看到其中的一些CQRS。

在报告方面，它只需要执行查询，而不必直接进入数据库。在此处浏览您的界面和您的域层。这是与主要任务不同的问题领域，但是您仍然需要遵循一些逻辑。

一旦您直接进入数据库，便会更加依赖它，它最终可能会干扰原始应用程序的数据需求。

另外，至少对我来说，我绝对更喜欢编写测试和开发代码，而不是查询或存储过程。我也喜欢在绝对必要之前不要将自己锁定在特定工具上。

由于响应延迟，缺少对数据服务资源的直接内存访问以及容错性等问题，在包括Internet在内的广域网中检索大量信息是有问题的。

此问题描述了一种设计模式，用于解决处理返回大量数据的查询的结果的问题。通常，这些查询将由具有一个或多个中间层的跨广域网（或Internet）的客户端进程对驻留在远程服务器上的关系数据库进行。

该解决方案涉及实现数据检索策略的组合，包括使用迭代器遍历数据集并为客户端提供适当的抽象级别，数据子集的双缓冲，多线程数据检索以及查询切片。

通常将运营/交易数据存储与报告分开。后者可能出于法律原因（例如，用于财务审计的七年财务数据）需要保留数据，而您不希望所有这些都保存在交易数据存储中。

因此，您将按一定时间（每周，每月，每季度，每年）对事务数据进行分区，并通过ETL将较旧的分区移至报表/历史数据存储中。它可能是也可能不是具有星型模式和维度的数据仓库。您将使用数据仓库报告工具进行临时查询，汇总和批处理作业以生成定期报告。

我不建议针对您的交易数据存储进行报告。

如果您想继续按下，这里还有更多想法：

1. “最佳”是主观的，什么有效。
2. 我会购买报告产品，而不是自己写报告。
3. 如果您使用的是关系数据库，那么SQL是该镇唯一的游戏。
4. 存储过程取决于您是否具有编写它们的技能。

您在家中使用的项目管理软件？我会先买，然后再建。Rally和Microsoft Project之类的东西。

首先是一些术语，您称为任务方的称为事务性，而报告方为Analytics。

您已经提到了CQRS，这是一个很好的方法，但是很少有文档记录该方法的实际应用。

经过严格测试的是使用分析处理引擎来补充您的事务处理。有时将其称为数据仓库或数据多维数据集。与分析有关的最大难题是，尝试针对您的事务数据实时运行查询充其量是效率低下的，因为实际上只能优化数据库以进行读取或写入。对于事务，您需要较高的写入速度，以避免处理/事务处理中的延迟。对于报告，您需要较高的读取速度，以便可以做出决定。

如何解决这些问题？最简单的理解方法是对报表和ETL（提取转换负载）使用扁平化的架构，以将数据从规范化的事务架构传输到非规范化的分析架构。ETL定期通过代理运行，并预加载分析表，以便可以从报表引擎中快速读取该表。

Ralph Kimball 撰写的《数据仓库工具包》是一本很好的书籍，可以让您快速掌握数据仓库。如需更多动手方法。下载SQL Server试用版，并获取Microsoft数据仓库工具包，该工具包对第一本书进行了一般性讨论，但展示了如何使用SQL Server应用这些概念。

这些页面中有几本链接的书，其中包含有关ETL，星型模式设计，BI，仪表板和其他主题的更多详细信息，以帮助您继续前进。

从您所处的位置到想要成为的位置的最快方法是雇用BI专家，并在他实施您所需的东西时给他阴影。

报告方面呢？数据仓库是可以接受的，还是由于将业务逻辑合并到数据库以及数据本身而设计不当？

我认为您不是在谈论业务逻辑，这是更多的报告逻辑。用户如何处理此屏幕上的信息，仅仅是为了更新状态？您的域模型用于为交易操作建模，报告是另一个需要关注的问题。从SQL Server中提取数据或将其放入数据仓库对于报表方案来说是很好的。

您的域模型应强制执行域的不变式，例如项目成员不能同时预订同一项目，或者每周只能预订x个小时。否则，您无法预订该项目，因为它已经完成，等等。您可以复制域模型的状态（数据）以单独报告。

为了提高查询性能，您可以使用实例化视图。当针对您的模型进行某项操作（例如，花4个小时的人的时间来计划x）并且成功完成后，它可能引发一个事件，然后您可以将该事件存储在报告数据库中并为报告进行必要的计算。这样就可以非常快速地对其进行查询。

将您的事务和报告上下文分开放置，构建关系数据库用于报告域模型则不是。

编辑

关于该主题的有用博客文章http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

4年后，我再次发现了这个问题，对我来说，答案是什么。

根据您的应用程序及其特定需求，您的域/事务数据库和报告可以是单独的“系统”或“引擎”，也可以由一个系统提供服务。但是，它们在逻辑上应该是分开的-这意味着它们使用不同的方法来检索UI并向UI提供数据。

我希望它们在物理上是分开的（除了在逻辑上是分开的），但是很多时候您是将它们（物理上）一起启动的，然后随着应用程序的成熟，您将它们分开。

同样，无论哪种方式，它们在逻辑上都应该有所不同。可以在报告系统中复制业务逻辑。重要的是，报告系统得到的答案与域系统相同-但是很有可能会通过不同的方式到达。例如，您的域系统将有大量（非常可能）以过程代码实现的非常严格的业务规则。报告系统在读取数据时可以执行相同的规则，但是可以通过基于SET的代码（例如SQL）来执行。

这是您的应用程序体系结构的演变实际上可能是什么样的：

级别1-逻辑上分开的域和报告系统，但仍在相同的代码库和数据库中

级别2-逻辑上分离的域和报告系统，但现在具有同步的分离数据库。

级别3-逻辑上和物理上分离的域和报告系统，以及具有同步功能的分离数据库。

主要思想是报告和域具有根本不同的需求。不同的数据配置文件（读取与写入以及更新频率），不同的性能要求等。因此，它们需要以不同的方式实现，因此有必要对业务逻辑进行一些重复。

您的业​​务取决于设计一种方法来保持域和报表系统之间的业务逻辑最新。

需要报告/仪表板以显示活动项目的列表

每个项目的状态应作为静态，按计算和格式正确的信息存储在数据库中，并且任何模拟都应作为WebApp在客户端上进行处理。

以当前消耗率计算的预算用尽日期

此类投影不应按需运行。根据要求管理此信息，例如对资源，费率，任务，里程碑等进行计算，将导致计算层的广泛使用，而无需将这些结果再用于以后的调用。

想象一下分布式环境（私有或公共云），您将在计算层，数据库使用率低和完全缺乏缓存方面获得巨大的成本。

应该首先在域中运行它吗？性能如何？

您的软件设计应包括在“数据输入”期间（而不是在读取期间）执行对获得所需结果所需的计算进行归一化的能力。这种方法大大减少了计算资源的使用，并且首先创建了可以被客户视为“只读”表。这是创建坚实而简单的缓存机制的第一步。

因此，在完成软件体系结构之前，首先要进行搜索，可以是分布式缓存系统。

（request：aggregation）！= 1：1

因此，我的考虑是（对于第一个和第二个示例），尝试了解何时将数据标准化是适当的，并以减少每个客户端请求的聚合为目标。如果一个目标是获得一个可持续发展的系统，则不能为1：1（请求：汇总）。

在客户端上分配计算

另一个问题，在完成软件设计之前，可能是我们要委托客户端的浏览器进行多少规范化？

它被称为MV *，今天确实很流行，除此之外，其目的之一就是创建WebApp（单页应用程序），可以将其视为许多复杂应用程序的存在（幸运的是，我们向云提供商付款，这些费用在客户端执行）。

因此，我的结论是：

1. 了解执行数据表示实际上需要执行多少操作；

2. 分析其中有多少可以在后台完成（然后在归一化后通过缓存系统分发）；

3. 了解客户端可以执行多少操作，获取项目的配置，在WebApp的Views上运行它，从而减少在后端执行的计算；

使用缓存进行查询，使用域进行缓存。

stackoverflow上有一个称为“顶级用户”的功能。您可能会在“最高用户”页面的底部找到一行，说：“这些总计中仅包含非社区Wiki问题和答案（每天更新）”。这表明数据已缓存。

但为什么？

对于性能问题。也许他们对泄漏域逻辑也有同样的担忧（在这种情况下，“总计中仅包含非社区Wiki问题和答案”）。

怎么样？

我真的不知道他们是怎么做到的，所以这里只是一个猜测:)

首先，我们需要找到目标问题/答案。调度任务可以工作，只需获取所有潜在目标即可。

其次，让我们只看一个问题/答案。它是非社区维基吗？是30天内吗？使用领域模型很容易回答。计算票数，并在满意时将其缓存。

现在我们有了缓存，它们是域派生的输出。该查询既快速又容易，因为仅需应用简单的条件。

如果结果需要更“实时”怎么办？

活动可能会有所帮助。代替使用调度任务触发缓存，我们可以将流程分为多个子流程。例如，当某人对hippoom的答案进行投票时，我们将发布一个事件，该事件触发对hippoom的主要用户缓存的更新。在这种情况下，我们可能会看到频繁的快速小任务。

是否需要CQRS？

既不使用计划任务方法也不使用事件方法。但是cqrs确实有优势。缓存通常是高度显示的，如果一开始不需要某些项目，我们可能根本不会计算和缓存它们。具有事件源的CQRS通过重播事件来帮助重新构建历史数据的缓存。

相关问题：
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use大量操作具有丰富的域/ 19416703＃19416703

希望能帮助到你 ：）

免责声明：
我对使用域模型的应用程序缺乏经验。
我了解所有概念，并且已经思考了很长时间如何将这些概念应用于我正在处理的应用程序（这些应用程序具有丰富的域，但是缺少OO，实际的域模型等）。
这个问题也是我也面临的关键问题之一。我有一个解决方案，但是正如我刚才所说的...这只是我想到的一个想法。
我还没有在实际项目中实现它，但是我看不出为什么它不起作用的原因。

现在，我已经弄清楚了，这就是我想出的内容-我将使用您的第一个示例（项目指标）来说明：

当有人编辑项目时，无论如何，您都是通过域模型加载并保存它的。
此时，您已加载了所有信息，以计算该项目的所有指标（预算总额，迄今为止的工作量等）。

您可以在域模型中进行计算，并将其与其余域模型一起保存到数据库中。
因此Project，您的域模型中的类将具有某些属性，例如TotalBudget，EffortToDate等等，并且在存储您的域模型的数据库表中还将存在具有这些名称的列（在同一表中或在单独的表中... doesn没关系）。

当然，从此开始，您需要一次性运行以计算所有现有项目的值。但是之后，每次通过域模型编辑项目时，数据将使用当前的计算值自动更新。

因此，无论何时需要任何种类的报告，所有必需的数据都已经存在（预先计算），您可以执行以下操作：

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

无论是直接从存储域模型的表中获取数据，还是以某种方式将数据提取到第二个数据库，数据仓库或其他任何东西都没关系：

1. 如果您的报告存储区与实际数据存储区不同，则只需复制“域模型表”中的数据
2. 如果您直接查询您的实际数据存储，则数据已经存在并且您无需计算任何内容

无论哪种情况，用于计算的业务逻辑都在一个地方：领域模型。
您在其他任何地方都不需要它，因此没有必要重复它。