我们应该通过多个有界上下文使用多少个事件存储?

inf*_*rno 3 domain-driven-design event-sourcing bounded-contexts

我目前正在阅读有关DDD的内容,但我无法找到这个问题的答案.如果我们有一个包含多个有界上下文的大型应用程序,那么据我所知,我们应该实现每个BC,因为它是一个单独的应用程序.因此,可以得出结论,每个BC都有自己的UI和事件存储.我之前认为我们只有一个事件存储器,因为根据一些文章(关于CQRS)它是单一的事实来源.这些陈述的唯一问题是他们缺乏背景.那么事件是在单个有界上下文中还是在整个应用程序中存储单一事实来源?

Dar*_*iss 5

  "Is an ES the single source of truth in a bounded context or in entire application?" 
Run Code Online (Sandbox Code Playgroud)

我猜你的意思是系统,因为Bounded Context是最简单的解释中的一个应用程序.

 "If we have a large application with multiple bounded contexts"
Run Code Online (Sandbox Code Playgroud)

您不能在同一模型中拥有多个有界上下文.有界上下文限制模型.所以,你应该改变长期bounded contextsubdomain,这将是正确的.

无论如何回答你的问题.这取决于.

整个系统的单一事件存储

优点

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

缺点

  • 单点故障(当然你可以扩展它,以避免这种情况)
  • 你将服务结合在一起(打破微服务的规则)
  • 在系统生命周期内,不要改变ES

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

优点

  • 没有单点故障
  • 部署应用程序
  • 服务之间没有耦合.更多的自主权
  • 如果应用程序将被禁用,则可以将其废弃
  • 新服务可以使用新版本甚至是不同的ES

缺点

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