11
在域丰富的应用程序中检索报告和仪表板数据的最佳实践或设计模式
首先，我想说这似乎是一个被忽略的问题/领域，因此，如果这个问题需要改进，请帮助我将此问题变成一个有益于他人的好问题！我正在寻求实施解决方案的人员的建议和帮助，而不仅仅是尝试的想法。 根据我的经验，应用程序有两个方面-“任务”方面，这主要是域驱动的，用户可以在其中与域模型（应用程序的“引擎”）进行丰富的交互，而报告方面则是用户根据任务侧发生的情况获取数据。 在任务方面，很显然，具有丰富域模型的应用程序应在域模型中具有业务逻辑，并且数据库应主要用于持久性。分离关注点，每本书都为此而写，我们知道该怎么做，太好了。 报告方面呢？数据仓库是可以接受的，还是由于将业务逻辑合并到数据库以及数据本身而设计不当？为了将数据库中的数据聚合到数据仓库数据中，您必须对数据应用业务逻辑和规则，并且该逻辑和规则不是来自您的域模型，而是来自您的数据聚合过程。错了吗 我致力于业务逻辑广泛的大型财务和项目管理应用程序。在报告这些数据时，我经常会做很多汇总工作以提取报告/仪表盘所需的信息，并且这些汇总中有很多业务逻辑。为了提高性能，我一直在使用高度聚合的表和存储过程进行此操作。 例如，假设需要一个报告/仪表板来显示活动项目的列表（设想10,000个项目）。每个项目将需要显示一组指标，例如： 总预算 迄今为止的努力 燃烧率 以当前消耗率计算的预算用尽日期 等等 这些都涉及很多业务逻辑。我不仅在谈论乘数或一些简单的逻辑。我说的是为了获得预算，您必须应用一个包含500个不同费率的费率表，每个费率适用于每个员工的时间（在某些项目中，其他项目具有乘数），应用费用和任何适当的加价等。逻辑是广泛的。为了使客户端在合理的时间内获得大量数据，需要进行大量的聚合和查询调整。 应该首先在域中运行它吗？性能如何？即使使用直接的SQL查询，我也无法获得足够快的数据以使客户端在合理的时间内显示。我无法想象如果要重新为所有这些域对象补水，并在应用程序层中混合，匹配和聚合它们的数据，或者试图在应用程序中聚合数据，那么尝试将这些数据足够快地发送到客户端。 在这些情况下，SQL似乎擅长处理数据，为什么不使用它呢？但是，那么您在域模型之外就有了业务逻辑。对业务逻辑的任何更改都必须在您的域模型和报告聚合方案中进行更改。 对于域驱动设计和良好实践，如何设计任何应用程序的报告/仪表板部分，我实在感到茫然。 我添加了MVC标签，因为MVC是jour的设计风格，并且在我当前的设计中使用了它，但无法弄清楚报告数据如何适合此类应用程序。 我正在寻找这方面的任何帮助-书籍，设计模式，谷歌关键字，文章等等。我找不到有关此主题的任何信息。 编辑和另一个例子 我今天遇到的另一个完美的例子。客户需要为客户销售团队提供报告。他们想要看似简单的指标： 对于每个销售人员，他们迄今为止的年销售额是多少？ 但这很复杂。每个销售人员参加了多个销售机会。有些人赢了，有些人没有。在每个销售机会中，都有多个销售人员，每个销售人员根据其角色和参与度分配一定比例的销售功劳。因此，现在想象一下要遍历该域...为每个销售人员从数据库中提取此数据所需要做的对象补液量： 获取所有SalesPeople-> 对于每个获取其SalesOpportunities-> 对于每个获取其销售百分比并计算其销售金额， 然后将所有SalesOpportunity销售金额相加。 这是一个指标。或者，您可以编写一个SQL查询，该查询可以快速有效地完成并对其进行快速调整。 编辑2- CQRS模式 我已经阅读了有关CQRS模式的信息，尽管很有趣，但即使是马丁·福勒（Martin Fowler）也说它未经测试。那么BEEN过去如何解决这个问题。每个人在某个时候或某些时候都必须面对这一点。具有成功记录的既定方法或陈旧方法是什么？ 编辑3-报告系统/工具 在这种情况下，要考虑的另一件事是报告工具。Reporting Services / Crystal报表，Analysis Services和Cognoscenti等都希望从SQL /数据库获取数据。我怀疑您的数据稍后会通过您的业务。然而，在许多大型系统中，它们和其他类似的对象仍然是报告的重要组成部分。在这些系统的数据源甚至报告本身中甚至存在业务逻辑的地方，如何正确处理这些数据？