架构案例 | 如何设计服务边界？

01 问题背景

在公众号DDD和微服务上，作者付施威提出了一个关于订单服务接口设计的问题。问题中涉及到两种设计：传递用户ID或传递用户基本信息至订单服务。

02 两种方案的不足

方案1强调易用性，但可能导致需要频繁的级联修改。若用户服务的模型更改，所有依赖服务，包括订单服务，都需调整。

方案2强调服务的独立性，避免了方案1的耦合问题，但可能将业务逻辑转移到编排服务，导致订单服务退化为单表服务，形成一个分布式单体系统。

03 认知负载问题

团队规模和服务数量影响了服务拆分的决策。在多团队协作环境中，无论选择哪个方案，用户模型都是团队共同的认知负担，影响开发效率。

04 解决思路

限界上下文强调在特定上下文中保持概念一致性，而非全局一致性。在订单服务的上下文中，应关注买家和卖家的概念，而非用户。

05 解决方案: 角色扮演

角色扮演概念将用户区分为买家和卖家，从而避免单一服务对用户模型的直接依赖。这使得服务变更时，只需在编排服务中适配买家和卖家模型，减少了耦合和影响范围。

06 反思：微服务本质

微服务不仅是对数据的增删查改，而是围绕业务能力组织的服务。微服务应提供独立的业务能力，由独立团队开发和维护，支撑更大的业务需求。