domain-driven-design - 我们应该由多个有界上下文使用多少个事件存储？

Question

我目前正在阅读有关 DDD 的信息，但我没有找到这个问题的答案。如果我们有一个包含多个有界上下文的大型应用程序，那么据我所知，我们应该实现每个 BC，因为它是一个单独的应用程序。因此，得出每个 BC 都有自己的 UI 和事件存储的结论是合乎逻辑的。我之前认为我们只有一个事件存储，因为根据一些文章(关于 CQRS)，它是唯一的事实来源。这些陈述的唯一问题是它们缺乏上下文。那么事件存储是单个有界上下文中还是整个应用程序中的单一事实来源？

Answer 1

  "Is an ES the single source of truth in a bounded context or in entire application?" 

我猜你的意思是系统，因为有界上下文是最简单解释的应用程序。

 "If we have a large application with multiple bounded contexts"

同一模型中不能有多个有界上下文。有界上下文限制模型。所以你应该改变术语 bounded context为 subdomain这是正确的。

总之回答你的问题。这取决于。

整个系统的单一事件存储

优点

一站式管理

通过CorrelationID很容易看到相关事件

在某些软件中不需要服务发现。所有服务(应用程序)都可以通过单个 ES 集成(我说的是真正的 ES，而不是数据存储。)

需要更少的 CPU/内存

缺点

单点故障(当然你可以扩展它，以避免这种情况)

您将服务耦合在一起(违反微服务规则)

有义务在系统生命周期内不更改 ES

每个应用程序一个事件存储

优点

无单点故障

与应用程序一起部署

服务之间没有耦合。更多自主权

如果应用程序将被禁用，ES 可以被禁用

新服务可以使用新版本甚至不同的 ES

缺点

需要关注和监控的其他数据库

更多的 cpu/ram 消耗

更难管理相关性 ID，因为它们在多个 ES 之间拆分

需要一些服务发现。用于订阅多个 ES 或需要额外的消息队列