在微服务中，事务边界是有界上下文还是聚合？

Question

可能第一个问题应该是：什么可以帮助我决定我的微服务是否应该包含一个可能有多个聚合的整个有界上下文，或者它应该只包含一个聚合？

如果微服务包含多个聚合，那么我脑海中就会出现另一个问题：微服务应该有多个事务边界（每个聚合一个）还是只有一个事务边界（有界上下文）？

也许，这些问题的答案是：视情况而定。但我想有一些理由来做出正确的决定。

我尝试实现一个实验性微服务，该微服务实现了由 3 个聚合和每个聚合一个事务边界组成的有界上下文，但我遇到了一些痛点：

• 微服务本身的最终一致性
• 以弹性方式在微服务中原子更新聚合和发布域事件
• 决定是所有领域事件都应该对外发布（给其他微服务）还是只发布其中的一部分
• 决定是否以集成事件的形式发布领域事件，以保持领域模型的纯度

然后我设想了将微服务拆分为多个微服务的可能性，每个微服务一个：

• 发布所有领域事件变得更自然（无需明确区分领域事件和集成事件）
• 微服务内部复杂度降低

我还没有找到关于这个主题的一些文档来指导我做出决策。

编辑：

考虑到有界上下文可以是一组作为合作伙伴一起工作的微服务，并且每个微服务将使用自己的扩展策略封装一个且仅一个聚合，这是否有意义？

然后，每个微服务都有一个且只有一个改变的理由：聚合。

Answer 1

当然，答案总是“视情况而定”。但是，在这种情况下，大多数情况下，您希望微服务包含一组封闭功能所需的一切。注意我说的是“功能”，就像在业务功能中一样。不是技术功能，例如将“人”保存到桌子上，而是业务功能，例如“将资金从一个帐户转移到另一个帐户”，“保留座位”，诸如此类。

用您的话来说，这意味着包含一个事务边界，并且可能包含多个“聚合”。

所有这一切都是因为可维护性。当您修改给定的功能（或修复错误等）时，您会希望将其本地化为单个微服务。任何需要在微服务之间进行协调的事情通常要困难得多。您必须协调团队、协调部署等，而这正是微服务应该成为解决方案的目的。