【发布时间】：2020-10-27 18:18:20
【问题描述】：
不熟悉域驱动设计的所有细节，在微服务架构中将每个服务视为自己的域并反过来为每个服务构建一个事件存储是否有意义？
不完全确定单个整体事件存储对于整个系统的权衡可能是什么。例如，更难在系统中重放条件或调试跨服务依赖关系。
【问题讨论】：
标签： microservices cqrs event-sourcing
【发布时间】：2020-10-27 18:18:20
【问题描述】：
关键是要有一个明确的单一所有者 - 即，如果您共享一个商店，那很好，只要只有一个服务使用给定的一组流。
例如，在 NEventStore v5+ 中，这被编码为将“桶”作为存储中的一个细分 - 每个服务都以这种方式获得一组独立的状态。或者可以通过 SQL SB 中的多个 SCHEMA 执行相同的操作。
当然也有很多充分的理由要尽可能地分开
- 您不想让人们受到阅读交叉服务的诱惑
- 您想让服务分道扬镳 - 您不希望对服务 B 进行任何基础架构更改以要求部署服务 A
- 拥有一个可以与这个视图齐头并进的共享库也是一个滑坡
应该说，这种关注是符合微服务（以及之前的 SOA）自治原则的普遍约束
【讨论】：
-
是否允许消费者（读取模型）监听多个事件存储以构建复杂的投影？
-
嗯....没有“允许”。但一般的建议是，微服务之间的任何集成都是事物耦合的接口，随着时间的推移，理解、分析和版本控制的所有痛苦。因此，每一个都应该被明确地建模——也就是说，你将构建一些明确地展示其他人需要的任何事件的东西——如果你不这样做，你就会像使用任何其他架构一样快地获得一团泥浆。 （这就是为什么一般建议永远不要只使用完全相同的基础设施淘汰 N 个服务 - 对每个服务/上下文进行适当和单独的建模）
-
@ConstantinGALBENU 抱歉，忘记@你了
-
“你不想让人们接受阅读交叉服务的诱惑”是什么意思？
-
我认为这意味着执行相当于 SQL JOIN 的操作可能太容易了，您可以从其他服务中获取数据，因为如果共享 db 很容易做到这一点