服务拆分原则：DDD、限界上下文与拆分粒度

做微服务架构，最头疼的问题是什么？
我个人觉得，不是技术选型，不是服务治理，而是——怎么拆。

面试里问服务拆分，十个有八个答不上来。要么说「按业务功能拆」，要么说「按团队组织拆」。这些都对，但不够。真正让拆分变得可操作、可落地的，是领域驱动设计（DDD）这套方法论。

今天我们不扯大理论，聊聊实际怎么用DDD指导拆分，以及那些我在项目中踩过的坑。

为什么需要DDD？

先问一个问题：服务拆分的本质是什么？
说白了，是划清边界。

没有边界，服务之间互相调来调去，改一个功能要改五个服务，这叫「分布式单体」，不是微服务。

那边界怎么划？靠业务直觉？靠技术经验？
都不可靠。你需要一套结构化、可重复的方法论。

这就是DDD的用武之地。

领域驱动设计（DDD）——沟通的语言

DDD里面有三个关键概念，你面试必须能讲清楚：

• 通用语言（Ubiquitous Language）——团队内部、团队与业务方之间，用同一套词汇沟通。代码里的类名、方法名、数据库字段名，都得跟业务术语保持一致。
• 限界上下文（Bounded Context）——每个通用语言只在特定边界内有效。比如「订单」在销售上下文里是一种含义，在物流上下文里又是一种含义。
• 战略设计与战术设计——战略设计负责划边界、识领域；战术设计负责实现，比如实体、值对象、聚合、领域服务这些模式。

我记得第一次在一个电商项目里引入DDD，团队最大的阻力不是技术，是「不想学新概念」。后来我带着大家一起做了一场事件风暴（Event Storming），把业务专家和开发拉到一个会议室，用便利贴把业务事件、命令、聚合全贴出来。结果一上午就把整个订单流程的领域模型画清楚了。
嗯，从那以后没人再说DDD「不接地气」了。

限界上下文——微服务的天然边界

限界上下文，是DDD给微服务送的最好的礼物。

每个微服务，应该映射到一个限界上下文。
为什么？因为上下文内是内聚的，上下文间是解耦的。

我举个例子。

假设我们在做一个订单系统。

• 订单上下文：负责下单、支付、退款。里面你看到的是「订单」、「订单项」、「支付记录」。
• 库存上下文：负责入库、出库、盘点。里面你看到的是「库存单」、「仓库」、「货架」。
• 物流上下文：负责配送、签收、退货。里面你看到的是「运单」、「配送员」、「物流轨迹」。

这三个上下文都用到了「商品ID」，但含义完全不同。
订单上下文关心的是「哪个商品被买了」，库存上下文关心的是「哪个商品还有货」，物流上下文关心的是「哪个商品要配送」。

如果不加区分，把这三个逻辑揉在一个服务里，就会产生那张经典的「大泥球」架构图。

拆分粒度考量——粗与细的博弈

拆得太细，服务网格满天飞，光应付网络开销就够你喝一壶。
拆得太粗，又回到了单体应用，高可用高并发全部落空。

那么，到底拆多细才合适？

我个人习惯遵循这几条经验法则：

粒度策略	优点	缺点	适用场景
粗粒度	部署简单，跨服务调用少，运维成本低	功能内聚不够，影响范围大	小团队、快速验证阶段
细粒度	高内聚低耦合，独立迭代，独立扩缩容	网络开销大，分布式问题（一致性、超时）多	大团队、高并发、复杂业务
适度粒度	平衡了开发和运维成本	需要持续调优，没有固定标准	大多数互联网中大型项目

怎么判断「适度」？我给你三个参考指标：

1. 变更影响范围：改一个需求，需要改几个服务？1~2个是健康的，超过3个说明拆太细或边界划错了。
2. 数据一致性要求：如果多个服务必须强一致（比如转账），说明这几个服务可能不该拆开，或者应该用事务模式处理。
3. 团队规模：一个微服务最好由一个6~8人的小团队全权负责。如果一个团队同时维护3个以上服务，那服务可能拆得太细了。

知识体系总览

讲到这里，我们把这一章的核心逻辑理一理：DDD、限界上下文、拆分粒度，三者是一条线的。

实战中的避坑指南

最后，总结一下我在多个项目里遇到的共性问题，给你提个醒：

• 别把限界上下文等同于数据库表。一个上下文可以包含多张表，一张表也可以被多个上下文共享（通过视图或API，不能直连）。
• 别忽略了「通用语言」的价值。如果开发说「订单状态」，业务说「订单阶段」，得先统一术语再写代码。我见过最离谱的一次，业务说「已支付」跟开发理解的「已支付」差了3个状态转换——上线测试才发现。
• 拆分粒度不是一次定死的。随着业务发展，一个服务可以拆成两个，两个也可以合并成一个。关键是每个阶段都可衡量、可回退。我习惯把服务间的依赖关系画成一张图，每次重构都对照这张图评估影响范围。
• 警惕「过度工程。有些团队看了几篇DDD文章，上来就搞事件溯源、CQRS，最后连消费者都搞不懂。DDD是工具，不是目的。