当前位置:  开发笔记 > 编程语言 > 正文

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

如何解决《我们应该通过多个有界上下文使用多少个事件存储?》经验,为你挑选了1个好方法。

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



1> Dariss..:
  "Is an ES the single source of truth in a bounded context or in entire application?" 

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

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

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

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

整个系统的单一事件存储

优点

一个管理的地方

CorrelationID很容易看到相关事件

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

需要更少的CPU /内存

缺点

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

你将服务结合在一起(打破微服务的规则)

在系统生命周期内,不要改变ES

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

优点

没有单点故障

部署应用程序

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

如果应用程序将被禁用,则可以将其废弃

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

缺点

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

消耗更多的cpu/ram

更难管理correlationID,因为它们在多个ES之间分割

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

推荐阅读
李桂平2402851397
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有