第 26 章查询：领域报告

最新推荐文章于 2024-08-29 08:40:33 发布

一路向北01

最新推荐文章于 2024-08-29 08:40:33 发布

阅读量117

点赞数

分类专栏： DDD

本文链接：https://blog.csdn.net/u011789995/article/details/88683157

版权

6 篇文章 1 订阅

订阅专栏

第 26 章查询：领域报告

构建非过度耦合到领域结构的报告的指导原则

在使用事件溯源的应用程序中构建报告

对在属于一个有界上下文的报告和需要从多个有界上下文中集成数据的报告之间做出选择时所涉及的取舍进行探讨。

构建软件系统是为了支持业务的需求。这些需求不仅包括产生收益的功能，还包括评估业务执行情况的能力。

在你的应用程序中选择如何实现报告涉及考虑类似的权衡问题：开发速度，可维护性，性能，甚至可扩展性。

这里的报告被定义为用于一些分析目的的一组连贯数据的呈现。并非被管理者或者出于商业信息BI目的特殊使用的报告的这一正式概念。

让你所有的数据集中在相同的有界上下文中是最简单的报告场景。

这种情况下，不用担心分布式的问题，但是你做出决定时需要做的最大的决策就是，是否要在生成报告时使用你的领域代码。

#	报告生成方式
1	使用简单映射构建一个报告的最快方式大概就是使用领域对象并且将其属性映射到提供数据以及呈现构建视图所需逻辑的一个视图模型上。如何构建你的视图模型，可以使用一个Report Builder类来实现。但是这个生成report的性能会让人着急。直接使用以上的映射，那么可能需要公开领域对象上的额外属性，这样会增加服务层耦合到领域结构的可能性。为了降低多余耦合，可以使用中介模式。
2	使用中介模式使用中介模式，将你的视图模型传递到一个中介内，它本身会被传递到领域中。然后领域对象会与该中介交互，它会相应更新视图模型。

当性能和效率很重要的时候，或者再不希望通过复杂的层和映射时，许多DDD实践者都会直接从数据库中提取他们的报告。

在CQRS的应用程序中，会创建专用的，非规范化的数据副本，以便于需要他们的每份报告。

#
1	查询一个数据存储通过直接查询一个数据存储来构建报告会为你提供更大的控制权并且让你能够编写有效的查询。但是这种范式的分享是，违背了DRY的原则，即重复工作的原则。且修改维护遗漏风险较高。
2	读取非规范化视图缓存有时候，即便使用手工SQL直接查询数据的效率也会很低。基于这个原因，有些DDD实践者选择创建特定视图/报告的非规范化数据副本（视图缓存）。这里的非规范视图承担了Report Builder的复杂性，这样报告的查询就会简单。

从事件流构建投影

投影实际上只是对产生一些期望状态的事件流或基于原始流中事件内容的新流进行查询而已。

这个投影的查询，为了作出一份诊断分析，一个流会将每个月产生一个流事件。

当使用一个分布式系统时，比如：“战略模式：用于分布式领域驱动设计的模式”。

跨界报告的生成方法

1	事件驱动原则来创建一个专用的报告有界上下文，它会订阅大量的事件，这些事件具有本地存储在单个数据库中的所需的所有信息。
2	也可以转而使用更轻量级的方法，就是使用UI复合技术，“复合应用程序”。