基于微服务的事件存储

Question

不熟悉域驱动设计的所有细节,在微服务架构中将每个服务视为自己的域并依次为每个服务构建一个事件存储是否有意义？

不完全确定整个系统的单个整体事件存储可能会有什么权衡.例如,在系统中重放条件或调试跨服务依赖性更困难.

Answer 1

关键是拥有一个明确的单一所有者 - 即如果你共享一个商店,那很好,只要一个服务只使用一组给定的流.

例如,在NEventStore v5 +中,这被编成了一个"桶"是商店内的一个细分 - 每个服务都以这种方式获得一组孤立的状态.或者可以通过SQL SB中的多个SCHEMA执行相同的操作.

当然有很多很好的理由分开到最大值

应该说,这种关注是一种普遍的约束,符合微服务(以及之前的SOA)的自治原则.

嗯....没有'允许'.但一般的建议是,微服务之间的任何集成都是一个与事物耦合的界面,随着时间的推移,理解,分析和版本化的所有痛苦.因此,每一个都应该明确地建模 - 即你构建一些能够明确表达其他人需要的事件的东西 - 如果你不这样做,你就会像任何其他架构一样快速地获得泥球.(这就是为什么一般的建议是永远不要只使用完全相同的基础设施标记N个服务 - 适当地和单独地模拟每个服务/上下文) (3认同)