用分层架构驯服复杂业务：一个DDD落地样本

用分层架构驯服复杂业务：一个DDD落地样本分享一套DDD分层架构的落地样本，一份在业务里反复打磨出来的「边界说明书」。本文尽量把每个选择都标了「为什么」：为什么业务规则要单独抽一层、为什么事务只能放在一个地方、为什么持久化对象不能穿透到调用方。哪天某个「为什么」不再成立，对应的规则就值得重新讨论，这套思想也就能一直演进，不会变成一纸死规范。代码示例使用伪代码，不绑定具体框架和中间件；图里的模块名、类名也都换成了通用命名，方便你直接套用。一、总览：四层模块 + 五层调用链1.1 模块四层（顶层视角）四类模块对应四层职责，自上而下、从外到内：依赖方向（只能往下，不能往上）：应用层 → 聚合层 → 原子服务层（可跳层）应用层 / 聚合层 / 原子服务层 → 中间服务层唯一例外：center可直接依赖srv-adapter（防腐层）判定规则、归属细则、各层硬约束，下一节逐一展开。1.2 调用链五层（写请求视角）模块确定后，一个写请求从接入到落库要穿过的五层长这样：调用链文字版（与上图对应）：controller → service（Application）→ DomainSvc（Domain）→ repository → mapper → DB 接入 编排/事务 领域规则 仓储 持久化这五层是跨模块的：controller 在 BFF，service 到 mapper 在 center，没有哪个模块装下全部五层（见 2.1 / 2.4）。这里容易搞混：service 是 Application Service（应用服务），DomainSvc 是 Domain Service（领域服务），两者不是一回事。注: srv是service的缩写二、模块四层职责与边界2.1 原子服务层center-name职责：自持核心数据，承担该领域的主业务流程与不变量。维度规则数据自持核心数据，禁止跨中心直接读写库调用不能直接调其它中心的 API / Service；同步跨中心协作走聚合层（由 agg 编排各 center 的 Feign），异步协作走事件依赖可依赖srv-name（含 adapter 类防腐模块）Controller不加在这里，加在app-name命名center-name（user / auth / product / trade / payment / …）为什么：每个中心相当于一块独立的地盘，自己的数据自己管。你今天图省事，让订单中心直接去读商品中心的库，短期确实快；可等商品表一改字段，订单中心就跟着崩，两个团队互相踩脚。所以跨中心的活儿要么走聚合层编排，要么走事件异步传，各中心只管好自己暴露出去的那几个接口。2.2 中间服务层srv-name职责：技术能力 / 平台支撑，不承载业务语义。类型用途消息中心MQ 生产 / 消费检索中心检索能力调度中心定时任务防腐中心第三方对接（唯一允许被 center 直接依赖的 srv）约束：服务命名 = 能力名，不带业务语义（不要说OrderMessageService）第三方对接一律进防腐中心，业务方不许发起第三方 HTTP 调用为什么：技术的东西和业务的东西混在一起，升级起来最难受。MQ 换个版本、调度框架升个级、第三方接口换个 SDK，本来只是基础层的事，一旦跟业务逻辑搅在一起，就得拉着业务模块一起回归。拆开之后，这些升级只动中间服务层，业务代码一行不用改。2.3 聚合层agg-name职责：跨多个中心的编排。比如订单创建需要同时拉商品快照、调会员积分、调促销计算——这种「跨中心」逻辑落在 agg。调用方向：agg-name→ 多个center-name的 API 包，不直接调对方的 service 或读对方的库。什么时候拉聚合层：业务用例涉及 ≥2 个中心，且协调逻辑（顺序、超时、降级、并行）有复用价值时。如果只是一个用例一次性用一次，直接放在 BFF service 也行，不必为聚合而聚合。2.4 应用层app-name（BFF）职责：端侧接入，按终端形态裁剪。模块终端app-customerC 端（消费者移动端）app-adminB 端（管理后台）app-opsB 端（运营后台）app-openapi对外开放（第三方系统调进来）硬约束：每个 BFF 专属某一终端类型，不混用——C 端不挂管理后台的接口轻逻辑编排：业务规则不进 BFF（进 center 的 DomainSvc）接口按版本号隔离（/v1//v2），不通过条件分支兼容多端Controller 加在这里，不加在 centerBFF 的特殊调用链（没有 repository / mapper，数据来自远端域服务）：controller → XxxService（Application）→ DomainSvc（编排 Feign）→ 各 center *QueryApi / *Api三、模块内调用链五层详解3.1 controller（接入层）职责：接 HTTP、做请求参数编排、异常兜底、回统一响应。不要做：在 controller 里写业务判断 / 二次校验在 controller 里组装跨中心数据controller 直接注入 repository 或 DomainSvc（必须经 service，命令/写链路如此；读查询可短接，见第六节 CQRS）正例：@PostMapping("/order/create")publicResultOrderNoVocreate(@RequestBody@ValidatedCreateOrderReqreq){returnorderService.create(req);}@PostMapping("/product/query")publicResultProductInfoVoqueryProduct(@RequestBodyQueryReqreq){returnproductService.queryProductInfo(req);}为什么：controller 就是个门卫，负责把外面的 HTTP 请求翻译成内部方法调用，再把结果翻译回去。要是它一边翻译还一边做业务判断，就没人说得清「这条规则到底藏在哪个文件里」了——改一条规则得翻遍 N 个 controller。3.2 service（Application Service，应用服务）职责：业务用例入口、事务边界、跨 DomainSvc / 跨 repository 编排。关键属性：一个 service 方法 = 一个完整的业务用例（「下单」、「取消订单」、「查询订单详情」）事务边界在这里（@Transactional打在 service 方法上）方法名直接表达业务意图：checkUserPurchaseLimit、ensureOrderRefundable、createOrder可以依赖多个 DomainSvc（跨领域规则组合）、多个 repository（跨数据源组合）不要做：service 里写大量if/for做规则判断（这该是 DomainSvc 的事）service 里直接注入 mapper（必须经 repository）service 里同时承担 Application + Domain（领域规则抽到 DomainSvc）正例：publicinterfaceOrderService{/** * 校验用户下单数量是否已达限购上限（业务规则） */voidcheckUserPurchaseLimit(LonguserId);/** * 创建订单（含事务、跨多个domain调用） */OrderNoVocreateOrder(CreateOrderReqreq);}@ServicepublicclassOrderServiceImplimplementsOrderService{@ResourceprivateProductDomainSvcproductDomainSvc;// DomainSvc@ResourceprivateMemberDomainSvcmemberDomainSvc;// DomainSvc@ResourceprivateOrderDomainSvcorderDomainSvc;// DomainSvc@ResourceprivateOrderRepositoryorderRepository;// repository@Override@Transactional(rollbackFor=Exception.class)publicOrderNoVocreateOrder(CreateOrderReqreq){// 1. 跨域规则组合（Application 编排）productDomainSvc.checkPurchasable(req