事情是这样的，前阵子接手了一个号称“微服务化非常彻底”的项目，拆了二十几个服务，结果一个创建订单的流程要调七八个服务，一半的接口返回的都是些无关痛痒的状态字段。更抓狂的是，改一个商品逻辑得同时动商品服务、库存服务、营销服务，哪个先部署都要排半天队——典型的拆得越细越乱，最后变成分布式单体。
这让我又翻出了那本被翻烂的《领域驱动设计》，重新琢磨了一个老大难问题：到底怎么拆才不跑偏？书里的聚合、限界上下文说起来头头是道，但一落到代码上就全凭感觉，感觉这东西太不靠谱，所以我干脆写了个小工具，逼自己按规矩来。
脚本的功能很简单：你用一个 YAML 文件把领域模型描述出来，它帮你生成符合 DDD 分层架构的项目骨架，同时用一堆检查规则卡住那些容易犯的错误，比如跨聚合直接对象引用、服务间循环依赖、聚合过大等等。不是代码生成器，倒更像是一个“架构约束工具”，在还没写业务代码之前就先把边界锁死。
先看一个建模文件的大致样子：
# domain-model.yaml
contexts:order:aggregates:- name: Orderroot: trueentities:- OrderItemvalueObjects:- Address- Moneyinvariants:- "总金额 = 所有订单项金额之和"product:aggregates:- name: Productroot: trueentities:- SKUvalueObjects:- Pricecustomer:aggregates:- name: Customerroot: truevalueObjects:- ContactInfo
这部分基本就是照搬事件风暴后的产出，每个限界上下文是一个微服务的候选，里面再定义聚合根、实体、值对象。领域不变式也写进去了，虽然脚本现在还不会自动验证，但至少逼着你在动手前先想清楚。
核心生成逻辑我用 Python 写的，比较糙，但思路很直接。先加载 YAML，然后基于 Jinja2 模板输出文件结构：
import yaml
from jinja2 import Environment, FileSystemLoaderdef load_domain_model(yaml_path):with open(yaml_path, 'r') as f:return yaml.safe_load(f)def generate_service(context_name, aggregates):# 每个上下文就是一个顶层包base_pkg = f"com.example.{context_name}"for agg in aggregates:root_name = agg['name']# 生成聚合根类aggregate_file = f"{base_pkg}/domain/{root_name}.java"# 生成对应的 repository 接口repo_file = f"{base_pkg}/domain/{root_name}Repository.java"# 实体、值对象类似...
但真正救了我命的不是生成器，而是里面的校验逻辑。我写了一个 validate_model 函数，在生成前跑一遍检查，违反原则的直接报错中断，根本不给生成代码的机会。比如我最头疼的“跨聚合对象引用”，检查起来很简单：
def validate_no_cross_aggregate_references(aggregates):# 聚合根名集合agg_names = {a['name'] for ctx in aggregates.values() for a in ctx['aggregates']}for ctx_name, ctx in aggregates.items():for agg in ctx['aggregates']:# 检查实体和值对象的字段类型entities = agg.get('entities', [])for entity in entities:if entity['type'] in agg_names and entity['type'] != agg['name']:raise ValueError(f"跨聚合引用：{agg['name']} 中的实体 {entity['name']} "f"直接引用了另一个聚合根 {entity['type']}，只能通过 ID 引用！")
这个检查一旦被打断，你就不得不重新思考模型。就像上次我把 Order 里的 Customer 直接写成对象引用，脚本直接就报错了，逼着我改成 customerId，顺手就把服务间的数据耦合松开了。以前总觉得“通过 ID 引用”是句废话，真被脚本拦下来几次之后才渐渐养成了肌肉记忆。
还有一个常见的坑：限界上下文的依赖方向没有约束，最后出现循环依赖。脚本里我也加了一个简单的拓扑排序检查，把上下文之间的依赖（通过领域事件或者引用的 ID 类型推断）写成一个有向图，检测是否有环：
def check_context_dependencies(domain_model):# 构建依赖关系，例如 order 依赖 product 和 customergraph = {}for ctx_name, ctx in domain_model['contexts'].items():deps = set()for agg in ctx['aggregates']:# 从实体字段类型中提取属于其他上下文的聚合根...graph[ctx_name] = deps# 使用 Kahn 算法检测环...
一旦发现环，就直接报“上下文之间存在循环依赖，请考虑合并或引入防腐层”，逼着你当场重新划边界。这比在架构评审会上被人指出问题丢脸要强多了。
脚本最终生成出来的结构大概是这样：
order-service/src/main/java/com/example/order/domain/Order.java # 聚合根OrderItem.java # 实体Address.java # 值对象OrderRepository.java # 仓储接口application/OrderApplicationService.javainfrastructure/...
谈不上多优美，但它至少保证了每个服务里只有自己边界内的东西，不会手一滑就把隔壁 Product 的实体直接 import 进来写业务逻辑。而且因为每个服务都是从这个骨架长起来的，代码组织结构统一，新同事看两眼就能找到对应逻辑，不用在几千行的“上帝服务”里摸爬滚打。
说到底，这个脚本不是银弹，它只是把我自己踩过的坑用代码固化了下来。领域驱动设计落地难就难在，它给了你一大堆原则，可没人帮你把它们变成每天写代码时的“栏杆”。这个工具就是我的栏杆——撞上去会疼，但不会掉进沟里。如果你也在“微服务越拆越乱”的泥潭里挣扎，不妨试试给自己也搞一套这样的约束，不用多复杂，能卡住那几条最核心的原则就够了。