微服务拆分原则：领域驱动而非数据驱动
战略设计 · 第 5/15 篇
上一篇：《DDD 宏观与微观概念：限界上下文直觉》 · 下一篇：《战略建模三板斧：四色建模、用例分析、领域故事》
开头：微服务怎么拆，才不拆成「分布式单体」？
面试里常问「微服务如何拆分、原则是什么」——答案如果只停留在「按表拆」「按页面拆」，往往落地后仍是高耦合的分布式大泥球。DDD 给出的方向是：先建领域模型、划定限界上下文，再映射为微服务边界，而不是反过来用数据库表结构驱动业务划分。
本篇梳理从单体到微服务的演进动机，以及十条可操作的拆分原则，重点落在「领域驱动、分层守规、按变化频率与吞吐异构拆分」等实战要点。
一、从单体到微服务：为什么要拆？
1.1 单体的两个典型问题
中心化：数据集中在一个库、业务集中在一台（或一组同构）服务器上，形成单点风险。
高耦合：一个模块升级牵动全局；团队迭代、产品更替之后，模块边界模糊、依赖交织，架构逐渐「腐化」——这就是常说的大泥球（Big Ball of Mud）。
1.2 SOA 与微服务
SOA（面向服务架构）通过通用通信接口让软件组件可复用、可组合，适合跨系统整合。
微服务（Microservices）则强调小功能块、独立进程、轻量通信、独立部署。Martin Fowler 与 James Lewis 在 2014 年给出经典定义：每个服务围绕业务能力设计，通过 HTTP API 等轻量协议协作，可异构语言与存储实现。
从单体升级，通常需要微服务治理基础设施先行——注册发现、配置、链路追踪、CI/CD 等，否则「微服务化」只会放大运维与排障成本。
二、微服务拆分的十条原则
2.1 单一责任原则（SRP）
每个微服务只负责一块完整业务，粒度由业务与架构共同权衡。职责单一便于维护、测试与独立发布。
2.2 松耦合原则
服务之间通过 API 或发布订阅通信，尽量彻底解耦：
- 数据库也要解耦：避免多服务共享同一库表，否则数据不一致、故障难定位。
- 每个服务只管理自己的数据，拥有自己的存储，以保障扩展性与可靠性。
设计目标：小型、松散耦合、高内聚。
2.3 领域驱动，而非数据驱动或界面驱动
DDD 聚焦特定业务领域的软件设计；微服务天然适合「一个服务 ≈ 一个业务域的实现」。
正确顺序是：
- 建立领域模型
- 确定限界上下文
- 再拆微服务
若「数据驱动」——先定表结构再改领域逻辑；或「界面驱动」——按页面切服务——模型会随存储或 UI 抖动，核心业务难以稳定。
领域模型与领域服务应高度通用、稳定；接口层与应用层吸收外部变化，保护核心逻辑。
2.4 分层职责清晰，避免「微服务小泥球」
微服务把大泥球拆成「小颗粒」，但若服务内部不分层、下层越权理解业务、甚至出现下层调用上层，会退化成小泥球——耦合与调用关系同样混乱。
分层约定（只能外层调用内层）：
| 层次 | 职责 |
|---|---|
| 接口层 | 对外暴露服务 |
| 应用层 | 编排、组合领域能力 |
| 领域层 | 领域业务逻辑 |
| 基础层 | 为各层提供技术资源 |
上下层需交互时，用消息队列、中转服务等逻辑解耦，而不是破坏分层方向。
2.5 全方位监控与日志
微服务数量上来后，分布式调试是主要难点：日志分散、链路跨服务。每个服务都应有可观测性——指标、日志、追踪，便于定位失败原因。
2.6 CI/CD 与 DevOps
微服务应可持续部署：构建、测试、发布自动化，缩短上线周期，支撑独立演进。
2.7 按业务变化频率拆分
分离变与不变是领域设计的基本法则。变动频繁的需求与相对稳定的 capability 应分开：
- 高频变更 → 独立服务，减少波及面
- 稳态业务 → 少动、严测
2.8 按吞吐量拆分
识别高吞吐、性能敏感的能力，解耦为独立服务：
- 避免局部热点拖垮整体
- 可单独制定扩容、熔断、限流策略
2.9 按技术异构拆分
同一业务域内，若部分能力必须用不同技术栈（如 Go 网关 + Java 核心 + 大数据批处理），可按技术边界拆服务，各取所长。
2.10 小结
以上原则是底座；具体行业还需在合规、组织、团队拓扑（如康威定律）上再做定制。没有银弹，但领域边界 + 松耦合 + 分层守规能避免最常见的拆分失误。
三、与限界上下文的关系
战略设计里划定的限界上下文，在实现上往往对应微服务边界：上下文内的领域模型映射到一个（或一组）服务，完成从问题域到解决方案的落地。
下一篇将进入战略建模的具体方法；再往后会用事件风暴把通用语言落到协作建模上。拆服务之前，先把「业务说什么话、边界画在哪」说清楚，比急着拆库表重要得多。
本篇小结
| 要点 | 说明 |
|---|---|
| 拆分顺序 | 领域模型 → 限界上下文 → 微服务 |
| 避免 | 数据表驱动、界面驱动、共享数据库 |
| 服务内 | 严守分层，防止「小泥球」 |
| 扩展维度 | 变化频率、吞吐量、技术异构 |
微服务不是目标，可独立演进的业务能力边界才是；DDD 提供的是找这条边界的语言和方法。