第三章 服务拆分原则与策略：业务边界、数据拆分、领域驱动设计
本章节是微服务面试的“必考核心”。面试官会通过服务拆分问题考查你的架构抽象能力、业务理解深度以及DDD实战经验。掌握业务边界划分、数据拆分策略、领域驱动设计三大支柱，才能给出令人信服的回答。
面试问答卡片
问题1：如何对复杂业务系统进行微服务拆分？具体步骤是什么？
| 考察点 | 业务域分析能力、DDD战略设计、边界划分原则、实际项目经验 |
|---|---|
| 回答框架 | ① 事件风暴梳理业务域 → ② 划分限界上下文 → ③ 为每个上下文分配独立数据库 → ④ 定义领域事件与接口 → ⑤ 结合团队结构验证边界 |
| 示例回答 | 先通过事件风暴识别订单、支付、库存等核心域，以“订单状态变更”为线索确定限界上下文；每个上下文独立数据库，通过MQ解耦；最后反查团队沟通成本，订单与支付边界清晰则保留拆分。 （约85字） |
| 可能追问 | 如果两个域共享大量业务逻辑怎么办？如何判断服务粒度是否合理？ |
| 避坑提醒 | ❌ 不要按数据表结构拆分；✅ 优先按业务能力拆分，先粗后细。 |
问题2：服务拆分时如何处理数据拆分？有哪些常见策略？
| 考察点 | 数据库拆分经验、分布式事务思想、读写分离、CQRS理解 |
|---|---|
| 回答框架 | ① 每个服务独享数据库 → ② 禁止跨服务join → ③ 用事件驱动保证最终一致性 → ④ 读多写少场景引入CQRS → ⑤ 数据归档与分库分表 |
| 示例回答 | 核心原则“数据归属服务”：订单服务只操作用户订单库，查询用户信息通过API调用。需要跨数据的事务用本地事件表+MQ实现最终一致性；针对报表场景搭建只读副本，避免影响核心链路。 （约88字） |
| 可能追问 | 如何保证本地事件表与业务操作的事务一致性？如果MQ宕机如何处理？ |
| 避坑提醒 | ❌ 不要试图用分布式事务强一致性；✅ 拥抱最终一致性，做好补偿机制。 |
问题3：领域驱动设计（DDD）如何指导微服务拆分？举一个实际例子。
| 考察点 | DDD核心概念（实体、值对象、聚合、限界上下文）、战略设计与战术设计结合 |
|---|---|
| 回答框架 | ① 建立统一语言 → ② 战略设计：划分限界上下文 → ③ 识别聚合根 → ④ 设计领域事件 → ⑤ 每个限界上下文映射一个微服务（或一组服务） |
| 示例回答 | 电商订单域中，“订单”作为聚合根，内部封装订单项、金额值对象；限界上下文为“交易域”，独立成服务。商品库存与订单通过“库存锁定”领域事件异步通信，保证高可用。 （约90字） |
| 可能追问 | 聚合根内部的变更如何影响其他服务？是否每个限界上下文必须是一个微服务？ |
| 避坑提醒 | ❌ 不要强行将DDD所有概念套入代码；✅ 先聚焦战略设计，战术设计根据团队演进。 |
项目案例模板
项目：电商订单履约中台 - 从单体到微服务拆分
| 业务背景 | 原有单体订单系统承载正向下单、退款、物流、发票等多业务，每次发布全量回归耗时2天，需求响应慢。 |
|---|---|
| 规模指标 | 拆分后共12个核心服务；日订单峰值1200万；50+开发人员维护；发布频率从两周一次提升到每日多次。 |
| 技术栈 | Spring Cloud 2020（Gateway + Nacos + Sentinel）、Kafka、MySQL分库分表（ShardingSphere）、Redis、CQRS只读服务。 |
| 核心难点 | 订单状态机的复杂流转（30+状态）、分布式事务（支付与订单状态一致）、数据迁移与双写。 |
| 面试高频追问 |
|
| 可迁移回答话术 | “我们采用DDD战略设计驱动拆分：通过事件风暴梳理出订单、支付、库存、物流四个核心域，每个域独立数据库；为避免跨域调用，引入领域事件（库存锁定成功、支付完成）实现异步解耦；数据拆分采用垂直分库+历史归档，读服务引入CQRS。整个过程遵循‘高内聚低耦合’，最终使每个服务可以独立发布。” |
💡 面试加分点：主动提及“事件风暴工作坊”、“优先拆分变化最快业务域”、“用适配器模式隔离外部依赖”，展示你的工程落地细节。