11、事件驱动微服务边界的定义与设计

事件驱动微服务边界的定义与设计

1. 事件驱动微服务边界概述

事件驱动的微服务彼此高度解耦，这使得更改一个服务时不会影响其他服务。这种独立更改和部署的能力是支持快速增长和发展的业务的关键特性。然而，随着系统的发展，复杂性可能会阻碍我们实现高度可演进和解耦的架构。因此，组织和定义不断增加的服务之间的边界成为主要关注点。

虽然事件驱动架构本质上具有高度解耦性，但随着系统变得更加复杂，我们不能想当然地认为这种特性会一直保持。即使通过消息队列解耦，如果我们需要反复添加跨越多个服务的功能，这些服务往往会相互依赖于彼此的更改，这可能导致多个服务需要其他服务的更改才能发布的僵局。如果服务之间有清晰的边界，就可以控制这些依赖关系，就像在应用程序内部创建边界来分离应用逻辑和数据库逻辑一样。

定义微服务边界有多种方法，一个经验法则是：一起更改的代码放在一起。领域驱动的方法是一种合理的边界定义方式，因为领域往往比其他方法更稳定，围绕公司的领域定义边界有助于适应变化，同时限制对其他领域的影响，并且与公司的组织架构也有很好的相关性。不过，定义边界通常是多种方法的结合，领域方法只是一个合理的选择，而非唯一的方式。

2. 定义微服务边界的不同方法

2.1 组织架构

康威定律指出：“任何设计系统的组织，最终所设计出的系统结构都会与该组织的沟通结构一致。”在实际情况中，公司的组织架构确实会影响技术边界。例如，有一家公司的某个边界，从领域角度看，它与另一个现有边界应该合并，但由于负责更改它的团队与现有边界的团队处于完全不同的组织结构中，所以它成为了一个独立的边界。

这种情况不一定是错误的，在这种背景下，同一组织架构内拥有相同边界