最近帮几个团队做微服务改造，发现十个项目里有八个都卡在同一个坑上：边界没划对，拆出来的服务要么数据来回调，要么改个订单状态要锁十几张表，比单体还慢。大家总以为微服务就是拆得越细越好，结果业务一跑起来全是一致性事故，每天修数据修到怀疑人生。
说到底，就是没把领域驱动设计里那个“聚合”当回事。我举个最简单的例子，电商系统里的订单和订单行：
// 错误的拆法：把 OrderLine 当成一个独立微服务
// order-service
@Entity
public class Order {@Idprivate String orderId;private OrderStatus status;// 不再持有 lineItems，改为远程调用
}// lineitem-service（另一个微服务）
@Entity
public class OrderLine {@Idprivate String lineId;private String orderId;private String productId;private BigDecimal price;private int quantity;
}
这么一拆，你以为独立了，其实业务上订单状态变更必须保证所有 OrderLine 的状态也一致，比如订单取消要把所有行项目置为已取消，这时候你就得跨服务操作 — 要么用分布式事务（性能灾难），要么用事件最终一致（但订单状态和行项目状态不一致的窗口期，前端展示会乱），产品经理一天能提三个数据 bug。
DDD 的解法很简单：订单和订单行是同一个聚合，Order 是聚合根，OrderLine 只是聚合内的实体。代码该这样写：
// 订单聚合根，一个微服务内完成
@Entity
public class Order {@Idprivate String orderId;private OrderStatus status;@OneToMany(cascade = ALL, orphanRemoval = true, mappedBy = "order")private List<OrderLine> lineItems = new ArrayList<>();// 聚合根控制所有业务规则public void cancel() {if (this.status != PAID) {throw new IllegalStateException("只有已付款订单才能取消");}this.status = CANCELLED;for (OrderLine line : lineItems) {line.cancel(); // 内部一致性，一次事务搞定}}
}@Entity
public class OrderLine {@Idprivate String lineId;@ManyToOne@JoinColumn(name = "order_id")private Order order; // 反向引用，但对外部暴露只通过聚合根private String productId;private BigDecimal price;private int quantity;private LineStatus status;void cancel() { // package-private，不让外面直接调this.status = CANCELLED;}
}
这个边界一旦划对，数据库事务范围天然就在一个服务内，根本不需要分布式锁。很多团队一开始觉得订单行是“商品”的一部分，应该拆到商品域，结果商品团队根本不知道什么是订单行取消策略，接口越抛越脏。
问题是，一个中大型系统几十个聚合，怎么快速发现哪些地方存在跨聚合的强一致性依赖呢？靠人肉 review 太累，于是我自己写了个小脚本，专门扫描项目里的实体注解，把聚合边界和依赖关系画出来，再检查潜在的事务连环操。
脚本是 Python 3 写的，纯文本分析，不依赖编译，三分钟就能跑完一个微服务项目。核心思路是：解析 Java 源文件，识别 @AggregateRoot 和 @Entity 的类，然后检查字段里是否直接引用了其他聚合根，或者业务方法里有没有透传数据库操作跨聚合。大体的解析逻辑长这样：
import re, osdef find_aggregates(src_dir):aggregates = {} # 聚合名 -> 文件路径entities = {} # 实体类# 先扫出所有带 @AggregateRoot 和 @Entity 的类for root, dirs, files in os.walk(src_dir):for file in files:if not file.endswith(".java"):continuepath = os.path.join(root, file)with open(path) as f:content = f.read()class_name = re.search(r'class\s+(\w+)', content)if not class_name:continuename = class_name.group(1)if re.search(r'@AggregateRoot', content):aggregates[name] = pathelif re.search(r'@Entity', content):entities[name] = path# 然后分析每个聚合根内部的依赖（字段类型、关联表）dep_graph = {}for agg, path in aggregates.items():with open(path) as f:code = f.read()# 查找字段声明的类型，简单匹配其他聚合根名field_types = re.findall(r'private\s+(\w+)\s+\w+;', code)deps = [t for t in field_types if t in aggregates and t != agg]# 同时检查方法里有没有直接 new 或者注入 Repository 操作其他聚合repo_refs = re.findall(r'(\w+)Repository', code)cross_agg_repos = [r for r in repo_refs if r in aggregates and r != agg]if deps or cross_agg_repos:dep_graph[agg] = (deps, cross_agg_repos)return dep_graph
这段代码比较糙，就是靠正则，但是对付 90% 的 Spring 项目已经够用了。接下来，我可以继续跑一个检查，如果发现聚合 A 的方法里直接注入了聚合 B 的 Repository，并且同时用到了 @Transactional，那基本上就踩坑了：
def find_cross_agg_transactions(dep_graph, src_dir):risky = []for agg, (deps, repos) in dep_graph.items():# 找到该聚合的文件，检查是否在方法上同时使用了 @Transactional 和操作其他聚合path = aggregates[agg] # 假定 aggregates dict 可以拿到with open(path) as f:content = f.read()methods = re.findall(r'(?:(@Transactional.*?\n)?)\s*public\s+\w+\s+(\w+)\s*\(', content, re.DOTALL)for annot, method in methods:if '@Transactional' in annot:for repo in repos:if repo + '.' in content: # 简单判断调用risky.append(f'{agg}.{method}() 使用了 {repo}Repository，有跨聚合事务风险')breakreturn risky
会列出类似这样的输出：
Order.cancel() 使用了 InventoryRepository，有跨聚合事务风险
像这种检查，如果让架构师一个个代码 review，可能要到上线后接口挂了才能发现。我把这个小脚本放到 CI 里，每次合并代码自动跑一遍，至少能把最蠢的拆分错误挡在开发阶段。
当然，脚本只能抓模式，真正的聚合边界还是得跟业务专家一块聊，用事件风暴把聚合的不变条件理清楚。工具只是帮你把代码里已经出现的“冒犯”标出来，改不改得动，还看团队对 DDD 的理解程度。但至少，跑完这个小工具之后，团队里终于没人再把订单和订单行拆成俩服务了 — 这就值回写脚本花的那两个小时了。