domain-driven-design - ES/DDD 微服务中的报告

Question

我刚开始使用 ES/DDD，我有一个问题，应该如何在此架构中进行报告。让我们举一个典型的例子，您有一个客户聚合、订单聚合和产品聚合，它们都是独立的。

现在，如果我想跨所有 3 个聚合和/或服务运行查询，但每个数据都在一个单独的数据库中，可能一个是 SQL，一个是 MongoDB，还有一个是其他的。人们应该如何设计或能够运行需要跨这些聚合进行联接的查询？

Answer 1

您应该将Reporting设计为一个简单的read-model/projection，可能在它自己的bounded context中(BC)，它只是从其他限界上下文(Customer BC、Ordering BC 和 Inventory BC)中监听相关的events ) 并构建具有完整数据非规范化的所需报告(即在查询时您不需要查询原始来源)。

由于事件，您不需要任何连接，因为您可以维护一个附加到Reporting read-model 的私有(private)本地状态，您可以在其中存储临时外部模型并根据需要查询这些临时读取模型，从而避免对其他 BC 进行外部额外查询。

在这种情况下，不需要反腐败层，因为 Reporting BC 中不涉及写入模型。

事情真的就这么简单，因为您已经有了一个事件驱动的架构(您使用了Event sourcing)。

更新:

这个特殊的解决方案对于创建您事先没有想到的新报告非常方便。每次你想到一个新报告时，你只需创建一个新的读取模型(就像你编写它的源代码一样)，然后你重播它上面的所有相关事件。读取模型没有副作用，您可以随时重播所有事件(从时间开始)。

读取模型重建在两种情况下完成:

1. 你创建了一个新的阅读模型
2. 您通过监听新事件或算法与初始版本差异太大来修改现有版本

您可以在这里阅读更多内容:

1. DDD/CQRS specialized forum - Grey Young is there!
2. Event sourcing applied – the read model
3. Writing an Event-Sourced CQRS Read Model
4. A post in first group describing Read Model rebuilding

或者您可以使用以下文本进行搜索:event sourcing projection rebuilding