服务拆分没有想清楚就动手，是许多微服务项目走向失控的起点。有的团队按技术分层拆，拆出了用户服务、日志服务、工具类服务，结果一个下单流程要横跨七八个服务；有的团队按组织架构拆，人员一调整服务边界就名存实亡。这些问题的根源在于缺少一套识别业务边界的方法论，而领域驱动设计（DDD）恰好提供了这样一套从业务视角出发的拆分思路。本文围绕DDD的限界上下文、聚合、上下文映射等核心概念，讲清楚如何把它们落到微服务的拆分实践中。
为什么按技术维度拆服务几乎必然出错
按技术维度拆分是最容易被想到的方式，因为它看起来层次清晰：数据库一层、业务逻辑一层、接口一层。但这种拆法有一个致命缺陷，它割裂了业务流程的完整性。以电商下单为例，订单创建涉及库存扣减、价格计算、优惠核销，如果这些逻辑分散在所谓的业务逻辑服务里，那么任何一次需求变更都要同时修改多个服务，联调成本和发布风险都会成倍增加。
判断拆分是否合理有一个简单标准：看一个业务用例的变更影响面。如果修改一个业务规则经常需要同时改动三个以上的服务，说明这条业务线被切断了；反过来，如果某个服务里堆满了互不相干的功能，改一个模块要回归整个服务，说明拆得太粗。这两种情况都意味着边界画错了位置，而正确的位置应该由业务决定，不是由技术分层决定。
领域驱动设计给出的答案是：服务边界应该对齐限界上下文，也就是业务语言保持一致的范围。在库存上下文里，商品意味着可销售的数量和仓位；在商品上下文里，商品意味着标题、详情和类目。同一个词在不同上下文里有不同含义，这正是天然的服务边界。
用限界上下文和聚合确定服务的粒度
识别限界上下文的起点是事件风暴。把业务专家和开发拉到一起，先列出领域事件，比如订单已提交、库存已扣减、支付已完成，再找出触发这些事件的命令和相关的角色，最后把语义一致的事件聚成一组，每一组大致对应一个限界上下文。这个过程不需要多高深的工具，一面白墙加一堆便利贴就够了，关键在于让业务方参与，因为边界藏在业务语言里，不在代码里。
确定上下文之后，还要用聚合来控制边界内部的粒度。聚合是一组必须保持一致性的对象，由一个聚合根统一对外。一个常见的错误是把数据库的表关系直接当成聚合关系，结果订单聚合里塞了订单明细、收货地址、优惠券快照等一堆数据，一次下单要在一个事务里锁定大量记录。正确的做法是遵循小聚合原则：订单聚合只包含订单号、状态和明细列表，收货地址和优惠信息通过ID引用，跨聚合的一致性交给领域事件和最终一致性处理。
// 订单聚合根：只管理强一致的数据，外部信息用ID引用
public class Order {
private String orderId;
private OrderStatus status;
private List<OrderItem> items; // 订单明细属于强一致范围
private String addressId; // 收货地址只存ID，跨聚合引用
private String couponId; // 优惠券同样只存引用
// 提交订单是聚合内部的业务规则
public void submit() {
if (items.isEmpty()) {
throw new IllegalStateException("订单明细不能为空");
}
this.status = OrderStatus.SUBMITTED;
// 发布领域事件，由下游上下文自行处理
DomainEventPublisher.publish(new OrderSubmitted(orderId));
}
}聚合设计直接决定了服务的最小变更单元。一个聚合对应一张主表加若干从表，聚合之间通过事件同步，这样单个服务的数据库事务范围小，扩容和重构都容易。如果发现某个服务里需要跨聚合做强一致事务，通常说明这两个聚合应该合并，或者需要重新审视边界划分。
用上下文映射处理服务之间的协作关系
划定边界只是第一步，边界之间如何打交道同样重要。上下文映射描述了限界上下文之间的集成模式，常见的有防腐层、共享内核、客户方与供应方等。其中防腐层最值得投入：当订单服务需要调用外部的物流系统时，不要直接使用对方的接口模型，而是加一层转换，把物流系统的数据结构翻译成订单上下文的领域模型。
// 防腐层：隔离外部系统的模型变化
public class LogisticsFacade {
private ExternalLogisticsClient client; // 第三方物流的SDK
public ShippingInfo getShippingInfo(String orderId) {
ExternalTrackResult result = client.track(orderId);
// 翻译成内部模型，外部字段改名不影响订单上下文
return new ShippingInfo(result.getTraceNo(), translateStatus(result.getCode()));
}
private String translateStatus(int code) {
if (code == 1) return "运输中";
if (code == 2) return "已签收";
return "未知";
}
}防腐层的价值在于把变化挡在门外。第三方系统升级接口、字段语义调整，这些变化被限制在防腐层内部，订单上下文的领域模型不受波及。缺少防腐层的系统往往出现一种恶性循环：外部接口一变，核心业务代码跟着改，久而久之领域模型变成了外部系统的影子，边界名存实亡。
对于上下文之间的数据同步，优先考虑基于事件的异步集成。订单上下文发布订单已提交事件，库存上下文订阅后扣减库存，两个服务之间没有直接的接口依赖，耦合度最低。需要同步查询的场景则要谨慎，比如商品详情页要展示库存余量，可以在商品服务里维护一份库存快照，通过事件更新，避免实时的跨服务调用拖慢页面响应。
落地时的渐进式改造与常见误区
直接按理想的限界上下文一次性拆分风险很高，更稳妥的路径是先模块化再服务化。在单体应用内部按上下文划分模块，模块之间只允许通过接口和事件通信，禁止跨模块直接查数据库表。运行一段时间后，把变更最频繁、瓶颈最明显的模块率先拆成独立服务，其余模块保持在单体内。这种绞杀者式的渐进改造能让团队边验证边界边调整，代价远低于推倒重来。
落地过程中有几个高频误区值得警惕。第一个是为拆而拆，把一个上下文内部的聚合也拆成独立服务，导致一次操作要跨多个服务编排，事务和一致性问题成倍增加，聚合不应该低于服务的最小粒度。第二个是共享数据库，两个服务读写同一张表，表面上是两个服务，实际上边界完全没有建立，数据库表结构一改两边都得动。第三个是忽视团队沟通成本，上下文边界如果和团队边界长期错位，康威定律会让代码边界慢慢漂移回组织结构，所以服务归属应该尽量和负责的团队对齐。
最后给一份动手前的评估清单：业务用例的变更是否集中在一个服务内、是否存在共享数据库、跨服务调用的平均深度是否超过三层、领域术语在不同团队的理解是否一致。这几个问题答得越好，说明边界越健康。拆分微服务本质上是一次业务建模的过程，领域驱动设计提供的只是方法和语言，真正的边界最终要从业务中来，回到业务中去。