如何在 DDD 中实现仅子查询

Question

在过去的几个月里，我们正在尝试重构和改进基于 DDD 和六边形架构的后端服务的架构和风格。不幸的是，我们对 DDD 及其最佳实践非常陌生。

我们的产品是关于车队管理和监控的。我们拥有的一项功能是用户可以获得他们管理的车辆的报告。大多数情况下，这些报告是对数据库的简单查询，在应用程序层有一些聚合和域逻辑。这是我们出现的问题。对于大多数应用程序，我们在应用程序层使用 CQRS 并定义命令/查询处理程序。我们注入到这个处理程序以及我们的数据库和缓存的依赖项是使用存储库等抽象出来的。

对于报表功能（我不知道将其称为子域是否合适），我们不知道该怎么做以及如何设计实体。其中一些报告很复杂，涉及对为 db 提取的多个数据集进行连接、验证等，另一些是非常简单的查询，将它们全部压缩在查询处理程序中似乎不合适，我们不知道我们是否需要在这里或不是。所以我们不再陷入困境和困惑。

Answer 1

TL;DR：如果您不尝试应用 DDD 模式，您会怎么做？这样做。

---

报告通常是只读的。它们只是形式方便的信息副本。

这意味着您不需要“我们为了数据更改而将其视为一个单元的关联对象集群”（聚合），因为我们不会更改数据。您不需要存储库和工厂，因为您没有管理聚合生命周期。您不需要实体，因为您不需要信息更改规则。

“值对象”有时很有用，但将信息复制到值中以便您可以再次读取它是浪费时间。

（这种情况的例外可能类似于独立应用程序，其中您的报告是对当前存储在内存聚合中的信息的描述。）

Answer 2

需要考虑的一件事是 OLTP（在线事务处理）与 OLAP（在线分析处理）。这与 DDD 无关，而是与数据结构和他们试图解决的问题有关。

简而言之，OLTP 是通过利用参照完整性等来支持应用程序中的事务（例如插入和更新）； OLAP 是关于报告和分析以及构建数据以更好地支持这一点。

这取决于您的报告需求的完整程度（功能要求、数据结构/DDD 模型的复杂性、查找次数、数据量、用户行为、数据易变性等）。如果您认为权衡取舍是合理的，那么您可能需要在支持应用主要功能的内容和与报告相关的内容之间对您的应用进行逻辑划分。

有几种方法可以执行此操作：

• DDD 代码和 OLTP 数据库；由报告代码和 OLAP 数据库称赞。这个选项是最严厉的选项之一，但它也是最容易理解的 - 完全分离。
• 整个应用中的 DDD 代码，将“报告”作为“纯”DDD 的一部分。支持您认为合适的数据库结构。
• DDD 代码，将所有“报告”无缝且优雅地融合到现有的纯 DDD 代码中。支持您认为合适的数据库结构。