Domain driven design 多个有界上下文应该使用多少事件存储？

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

  "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"

同一模型中不能有多个有界上下文。有界上下文限制模型。所以，您应该为

子域

更改术语

有界上下文

，这是正确的

无论如何，回答你的问题。视情况而定

整个系统的单事件存储 专业人士

• 一个管理的地方
• 通过CorrelationID很容易看到相关事件
• 在某些软件中，不需要服务发现。所有服务（应用程序）都可以通过单个ES集成（我指的是真正的ES，而不是数据存储）
• 所需的cpu/内存更少

缺点

• 单点故障（当然，您可以扩展它，以避免这种情况）
• 您将服务耦合在一起（打破了microservice的规则）
• 有义务在系统生命周期内不更改ES

每个应用程序一个事件存储 专业人士

• 没有单点故障
• 与应用程序一起部署
• 服务之间没有耦合。更多自治权
• 如果应用程序将被禁用，则可以将其取消绑定
• 新服务可以与新版本甚至不同版本的服务一起使用

缺点

• 需要关注和监控的其他数据库
• 消耗更多的cpu/ram
• 更难管理CorrelationID，因为它们在多个E之间被拆分
• 需要一些服务发现。用于订阅多个ES或需要额外的消息队列

---

嗯，有趣的是，我不知道你可以选择，我认为有一个严格的规则。你为什么要假设一个微服务架构？你的答案似乎集中在微服务上，尽管这个问题与之无关。还是我误解了你的答案？我们在有限的上下文中讨论EventStore。我的答案基于微服务体系结构，你就在这里。但如何应用它：作为微服务体系结构、SOA体系结构或仅仅是noname分布式体系结构，这并不重要。如果你使用monolith应用程序，你不关心多个问题，因为它毫无意义。我不久前在DDD邮件组上问了一个类似的问题，遗憾的是没有得到令人信服的答案。但是，多个事件存储的缺点之一是会使所有这些存储中事件的重播变得复杂。你能把它们并行运行吗？串联？在此期间，您将如何对传入事件进行排队？有很多复杂的挑战，但指导您决策的材料却很少：）@Songo我觉得多个存储会更好。至少每个bc都应该是一个独立的应用程序。所以重播必须在bc级别进行，而不是由每个bc进行。至少这看起来合乎逻辑，但我也不确定。我会试着问一个有DDD经验的人，也许他会回答。@Songo我和那个人谈过，他更喜欢单事件存储，并且只有在有原因的情况下才使用多事件存储，例如不同的团队正在处理不同的bc-s，他们无法访问彼此的数据库，或者使用多事件存储更快，所以这里没有经验法则，我想我可以接受Dariss的答案。酷！他在用什么样的事件存储？据我所知，没有任何事件存储支持这种开箱即用的功能。我希望能找到一个支持分区的事件存储（即多个物理存储，但作为一个逻辑存储），就像数据库分区一样。@Songo为什么这么重要？我的意思是在当前的bc中，你只需要相关的事件。其他bc-s的事件充当命令（又名.saga），这可能导致当前bc中发生不同的事件。