【系统架构设计百科】DDD 与微服务：用领域模型划分服务边界
内容提要
某电商团队在微服务架构中按数据表拆分服务，导致下单请求需多次RPC调用，增加了延迟和故障风险。文章建议基于限界上下文划分服务边界，强调业务操作跨越多个实体的现实。通过七个启发式规则，帮助判断服务拆分的合理性，并提出团队组织应与架构对齐，以提高系统的可用性和维护性。
关键要点
-
某电商团队按数据库表拆分微服务，导致下单请求需多次RPC调用，增加了延迟和故障风险。
-
建议基于限界上下文划分服务边界，强调业务操作跨越多个实体的现实。
-
微服务的边界应对齐限界上下文的边界，一个限界上下文对应一个或一组微服务。
-
提出七个启发式规则帮助判断服务拆分的合理性，包括通用语言一致性、业务能力内聚、数据所有权等。
-
团队组织应与架构对齐，以提高系统的可用性和维护性。
延伸解读
微服务拆分的误区
许多团队在拆分微服务时，常常误以为按数据表划分服务是最佳实践。然而，实际情况是，业务操作通常跨越多个实体，导致频繁的RPC调用，增加了延迟和故障风险。正确的做法是基于限界上下文来划分服务边界，以确保服务的内聚性和独立性。
团队与架构的对齐
文章强调团队组织结构应与微服务架构相匹配。根据康威定律，团队的沟通结构会直接影响系统架构。因此，若希望系统按业务域拆分，团队也应按业务域进行组织。这种对齐不仅提高了开发效率，还能减少跨团队协作的复杂性。
服务拆分的启发式规则
为了合理判断服务拆分的边界，文章提出了七个启发式规则，包括通用语言一致性、业务能力内聚和数据所有权等。这些规则帮助团队在拆分服务时，确保每个服务能够独立完成特定的业务能力，降低服务间的耦合度。
延伸问答
为什么按数据表拆分微服务会导致问题？
按数据表拆分微服务会导致下单请求需要多次RPC调用，增加延迟和故障风险，任一服务超时会导致整体不可用。
如何基于限界上下文划分微服务边界？
微服务的边界应对齐限界上下文的边界，一个限界上下文对应一个或一组微服务，而非一个实体对应一个微服务。
有哪些启发式规则可以判断服务拆分的合理性？
七个启发式规则包括通用语言一致性、业务能力内聚、数据所有权、变更频率、伸缩需求、团队边界和故障隔离。
团队组织如何与微服务架构对齐？
团队组织应根据业务域进行划分，以确保团队结构与目标系统架构一致，从而提高系统的可用性和维护性。
微服务架构的演进路径是什么？
演进路径包括从模块化单体开始，逐步选择性拆分需要独立伸缩和部署的上下文，最终实现持续演进。
微服务拆分时需要考虑哪些关键原则？
关键原则包括逻辑边界先于物理边界，确保服务的独立性和可维护性，以及根据业务需求调整上下文边界。
