企业官网建设流程全解析

做导购返利APP，最绕不开的就是佣金结算。订单进来、推荐关系要匹配、返利比例要算、退款要冲正、平台补贴要分摊，最后还要跟外部渠道对账。我接手这类核心系统重构时，团队已经没人愿意在原来那套Service上继续叠if else了，于是我们把领域驱动设计（DDD）整套思路搬进了佣金结算模块——聚合根、限界上下文、防腐层，这些平时在PPT上抽象的概念，落到返利场景里其实是能把复杂度真正止住的东西。这篇就以佣金结算为主线，讲清楚我当时是怎么划分限界上下文、设计佣金单聚合根、以及用防腐层封堵外部渠道数据扰动的完整过程，给正准备做同类系统的同学一份可参考的落地方案。

1. 导购返利佣金结算：为什么偏偏是DDD的“试金石”

想理解这套架构选择的背后逻辑，得先回到业务本身。导购返利的核心链条看起来很简单：用户A通过专属链接邀请用户B注册，B在平台下单，系统按规则把佣金算给A。但真实世界永远比PPT复杂，佣金计算从来不是“订单金额乘以返利比例”这么干脆。

1.1 佣金规则从来不是“乘法”这么简单

我举一个实际会遇到的订单：一件原价199元的T恤，平台大促打八折变成159.2元，用户又领了一张20元优惠券，实付139.2元，而且是走邀请人链接进来的。这时候要回答的问题有一串：

• 佣金基数按实付139.2元算，还是按优惠前的159.2元算？
• 那20元平台补贴券，成本由谁承担，佣金要不要相应扣减？
• 邀请人当前等级是Lv3，对应返利比例是6%，还是8%？
• 商品本身还参加了类目扣点，类目佣金率和平台补贴叠加后，最终比例是多少？
• 如果B又邀请了C，两级邀请关系都命中，两笔佣金如何分别计算？

每个规则单独拎出来都不难，难的是它们组合在一起。更麻烦的是，返利比例随时可能被运营活动调整，会员等级体系可能变化，商品类目也会新增。如果这些规则的落点分散在多个Service里，需求一来，你根本不知道要去改哪里。

1.2 传统事务脚本把规则“摊平”了，问题出在“无归属”

我们最早那版系统走的是最常规的路子：一张commission_record表，一个RebateServiceImpl，订单支付回调进来就insert一条记录，用户提现时再按条件汇总金额。初期订单量小，还能撑住。

崩坏是从一次“限时补贴活动”开始的。产品经理上线了一个补贴规则：部分商品平台额外补贴5%作为佣金加成，但补贴只持续两周。开发在原来的Service尾部追加了一段逻辑算补贴，活动结束后前端配置下线了，但下游结算仍然按照带补贴的旧基数计算，结果产生了数千笔超额佣金。财务对账发现多发了钱，团队花了好几天手工冲正。

归根结底，事务脚本模式把业务规则摊平到了每一个方法里，没有归属。佣金规则一会儿在OrderService里，一会儿在RebateService里，一会儿又在某个监听器里。表面上看代码不多，实际上变化一来，牵一发动全身，而且没有人能说清楚“当前这个订单的佣金到底是怎么算出来的”。

1.3 DDD在这里真正管住了什么

回到DDD，它不是一个框架，而是一套约束。在佣金结算这个场景里，它核心解决了三件事：

• 限界上下文：让“返利规则”“订单数据”“用户分销关系”“资金账户”各有各的模型，谁都不许越界改别人的数据。
• 聚合根：把“佣金单”作为一个有生命周期的对象，所有明细变动都必须经过它，保护财务不变量。
• 防腐层：把外部导购渠道那套混乱的数据结构挡在核心领域之外，渠道字段怎么变，都别想污染内部模型。

再加上领域事件做上下文之间的异步协作，把“支付成功”“退款完成”“等级变更”这些事实传递出去，整个结算流程才真正变成一个可审计、可追溯的闭环。

2. 限界上下文：拿一张“关系地图”切开返利业务

限界上下文是DDD的第一步，也是最容易被跳过的一步。很多团队上来就想着怎么设计聚合根，但实际上边界没划清楚，聚合根设计得再漂亮也是白搭。

2.1 按“业务能力”切边界，而不是按“数据库表”切

我们最容易犯的错，是把开发时的模块划分直接当成限界上下文。以前一个订单模块包含订单表、订单明细表、优惠券使用记录表，一个用户模块包含用户表、用户等级表、邀请关系表，一个佣金模块包含佣金记录表、结算表。听起来很合理，但其实这是按“存放位置”切的，不是按“业务能力”切的。

DDD的思路是先找业务能力，再定上下文。在导购返利平台里，主要的能力域有这么几个：

• 商品浏览与类目管理：只关心商品、类目、售价。
• 用户身份与分销关系：维护用户信息、等级、上下级邀请关系。
• 订单履约：负责下单、支付、发货、售后，是订单事实的唯一来源。
• 佣金结算：负责按返利规则计算佣金、管理佣金单状态、生成结算记录。
• 资金账户：负责佣金入账、提现、与支付通道对接。
• 渠道对接：负责与外部导购联盟平台的接口交互。

有意思的是，同一个词在不同上下文里含义完全不同。订单上下文里的“订单”有收货地址、物流单号、售后状态；佣金上下文里的“订单”只需要订单号、用户ID、实付金额、商品类目和时间。如果强行让两个上下文共享同一张订单表、同一个Order实体，语义就被搅浑了。

2.2 订单、分销、结算三个上下文之间的协作规则

划好边界之后，更重要的是定协作规则。我们当时重点梳理了三个上下文的关系。

订单上下文是整个系统的事实来源，它不关心任何返利规则，只需要在订单支付成功、退款完成、订单取消时发布领域事件。分销上下文维护“谁邀请了谁”，它对外提供查询接口，也发布等级变更事件。佣金结算上下文订阅订单事件和分销事件，在本地生成佣金单，并在佣金状态变化后向资金账户上下文发出入账请求。

这里有一条红线：下游上下文不能反向操作上游上下文的数据。佣金结算不能因为要算佣金就直接去更新订单表的某个字段，也不能去改分销关系。它只能基于收到的事件和查询结果做自己的计算。这样依赖方向是单向的，才不会出现订单服务因为佣金规则变更而跟着发版的情况。

2.3 模糊地带怎么判：退款、等级变更就是典型的“谁都沾”

实际划分边界时，最纠结的往往是那些“谁都能沾一脚”的业务场景。退款就是典型例子。

从数据归属看，退款是订单上下文的动作；但从影响看，退款直接决定佣金要不要收回。如果图省事，让订单上下文在处理退款时“顺便把佣金扣了”，那佣金规则就被泄露到了订单上下文，以后返利比例一变，订单服务也得跟着动。

我们的处理方式是：订单上下文只发布“订单退款完成”事件，事件里携带订单号、退款金额、退款时间，不包含任何佣金计算内容。佣金结算上下文自己监听到事件后，根据本地佣金单的当前状态决定是生成冲正明细，还是从待结算金额中扣减。等级变更同理，分销上下文发“用户等级变更”事件，结算上下文再决定未结佣金是否按新等级重新计算。

边界模糊不可怕，可怕的是用“共享数据表”来弥合模糊，那等于没有边界。

3. 聚合根：让佣金单成为一个有主张的领域对象

限界上下文把系统切成几块之后，每个块的内部还需要进一步设计。聚合根就是块内部的结构中心。说直白点：佣金单不能是一张谁都能往里面塞数据的表，它必须是一个自己会算账、会拒绝不合理操作的对象。

3.1 为什么不能拿佣金明细表直接做外部CRUD

我们旧系统的核心问题就是佣金数据模型失去了“主导权”。上游订单回调进来，代码直接向commission_record表插入一条记录；运营和客服偶尔还会手动修改某些异常数据；提现时再全表扫一遍做汇总。

结果就是没有任何机制保证“明细之和等于总额”“同一订单不会重复入账”“退款后佣金状态正确”。曾经出现过一次线上事故：客服手动修改了一笔异常佣金后，把关联订单重新触发了一次计算，金额翻倍，月底对账两三天才查出来。

聚合根解决的就是这个“主导权”问题。外部想动佣金数据，只能通过聚合根暴露的行为方法，比如addLineItem()、reverse()、approve()，而不是直接拿到明细集合改字段。

3.2 佣金单聚合的范围与不变量

我们先圈定聚合根CommissionOrder的内部结构：

• 聚合根：佣金单，持有整张单的状态、总金额、账期。
• 内部实体：CommissionLineItem，每一条佣金明细，包含订单号、计算基数、返利比例、计算金额、关联事件ID。
• 值对象：Money金额、CommissionRuleSnapshot规则快照（把当时的返利比例、补贴比例等参数固化下来，防止后续规则变化影响历史账单）。

聚合根要保证的不变量有三条：

1. 账平：所有明细金额之和必须等于佣金单总额。
2. 幂等：同一笔订单在相同账期内只能入账一次。
3. 可追溯：退款冲正不能物理删除原明细，只能新增负向调整记录，保留完整的审计链路。

为什么非要这些不变量？因为财务场景下，任何一条被绕过的“小改动”都可能变成月底对不上的大窟窿。聚合根的价值就在于把这些规则固化成代码约束，而不是靠程序员自觉。

3.3 代码骨架：一个有立场、有行为的佣金单

下面是我倾向于使用的聚合根写法，去掉了辅助代码，保留核心逻辑：

public class CommissionOrder { private CommissionOrderId id; private String userId; private List<CommissionLineItem> items = new ArrayList<>(); private Money totalAmount = Money.of(0); private CommissionStatus status = CommissionStatus.PENDING; // 供持久化框架使用的保护构造，外部不能 new 一个不完整对象 protected CommissionOrder() { } public void addLineItem(OrderPaidEvent event, RebatePolicy policy) { // 幂等校验：同一账期内同一订单只能入账一次 boolean exists = items.stream() .anyMatch(item -> item.getOrderId().equals(event.getOrderId())); if (exists) { return; } Money amount = policy.calculate(event); items.add(CommissionLineItem.fromPaidEvent(event, amount)); recalculateTotal(); this.status = CommissionStatus.CALCULATED; } public void reverse(OrderRefundedEvent event) { CommissionLineItem target = findItemByOrderId(event.getOrderId()); if (target == null) { return; } // 负向冲正，保留原明细用于审计 items.add(CommissionLineItem.adjustment( target.getOrderId(), target.getAmount().negate(), event.getRefundAt())); recalculateTotal(); this.status = CommissionStatus.PARTIALLY_REVERSED; } public void approve() { if (!status.canApprove()) { throw new IllegalStateException("当前状态不允许审核"); } this.status = CommissionStatus.APPROVED; } private void recalculateTotal() { this.totalAmount = items.stream() .map(CommissionLineItem::getAmount) .reduce(Money.of(0), Money::add); } }

注意几个细节：

• 我没有提供getItems()返回可修改集合，外部只能通过行为方法触达明细聚合，这才是聚合根的“保护力”。
• 构造函数是protected，给JPA这类ORM框架留了代理入口，外部ApplicationService必须通过createCommissionOrder()工厂方法创建。
• RebatePolicy是一个领域服务接口，具体的返利计算策略可以在领域层内部自由替换，但调用入口始终在聚合根这里。

3.4 事务边界：一次方法调用只改一个聚合，别跨聚合开大事务

接下来说一个我们付出了学费才明白的点：聚合根设计完毕之后，事务边界要跟着聚合根走，而不是跟着“方便”走。

一开始因为怕数据不一致，我们把“更新佣金单+更新用户账户余额+写资金流水”放到同一个@Transactional里。结果锁范围扩大、冲突频繁，而且一旦某个下游写操作超时，整条链路都跟着回滚，反而把失败面放大了。

后来的做法是：佣金单的状态变化在自身聚合内提交；资金账户的入账通过领域事件异步触发；账户侧通过事件ID做好幂等。佣金单和账户可以在不同时间达到最终一致，但对账脚本会帮你发现任何一步的偏差。

要记住一个原则：一个事务只改一个聚合根，跨聚合的业务流用事件或流程编排去衔接，而不是用一个大事务把多个聚合硬绑在一起。

4. 防腐层：把导购渠道的“脏模型”挡在领域之外

限界上下文解决内部边界，防腐层解决的是外部边界。导购返利APP通常要对接多个外部导购平台、广告联盟或上游商户，对方回传的数据结构往往和我们内部模型相差很远。防腐层就是两边模型之间的翻译隔离带。

4.1 上游渠道的模型和我们不是同一个物种

上游导购联盟回传的一个典型订单长这样：

{ "order_no": "XA10293847", "sub_orders": [], "pay_amount": 139.2, "item_list": [], "commission": 8.35, "extra": { "rebateRate": "0.06", "level": "novice" } }

问题很明显：pay_amount是BigDecimal，我们内部用Money值对象；extra里塞了各种规则相关字段，数据结构不稳定；commission字段是我们算的还是它算的，职责混乱。如果让领域层直接依赖这种DTO，一旦对方调整字段，我们整个佣金计算逻辑都要跟着改。

防腐层的本质工作就是：在外部模型和内部模型之间，建立一层翻译边界。外部字段的变化，只允许影响防腐层自身的代码，不允许传导到领域层。

4.2 防腐层的标配：适配器、翻译器、远程门面

防腐层通常由三部分组成：

• 适配器（Adapter）：负责接收外部请求，比如监听Webhook、定时拉取任务，或者调用外部接口。它只做协议对接，校验签名、鉴权、解析报文，不写业务。
• 翻译器（Translator）：把外部DTO翻译成内部Command或领域事件。这是防腐层最关键的部分。
• 远程门面（Facade）：封装对上游系统的主动调用，统一管理HTTP客户端、超时、重试、限流。

翻译器的工作示例：

public class ExternalOrderTranslator { public OrderPaidCommand translate(ExternalOrderDTO dto) { // 只做字段映射，不做业务判断 String category = dto.getExtra().getString("category"); return new OrderPaidCommand( dto.getOrderNo(), dto.getUserId(), Money.of(dto.getPayAmount()), category, Instant.parse(dto.getPaidAt()) ); } }

以我的经验，防腐层要作为一个独立模块存在，比如channel-acl，而不是把翻译代码散落在infrastructure目录里。因为散落的防腐层代码会逐渐失去边界意义，最后变成没人说得清的一段“胶水逻辑”。

4.3 防腐层的红线：翻译字段可以，翻译业务规则不行

防腐层最容易被越权。我见过不少代码，在翻译器里顺手写了这种逻辑：

if (dto.getPayAmount() > 5000) { // 走大额审核 }

这就是典型越权。“金额大于5000需要审核”是业务规则，它应该活在领域层或应用层的领域服务里，而不是被塞进防腐层。防腐层的职责边界非常窄：协议转换、格式映射、基础校验，仅此而已。

如果防腐层开始写业务规则，那么渠道一换，规则就跟着丢了，排查的时候你还会在错误的方向上浪费大量时间。这是防腐层最需要警惕的慢性病。

5. 领域事件与Outbox：从支付成功到佣金入账的可靠闭环

限界上下文之间靠事件协作，事件本身的设计和可靠性，决定了整套系统的数据一致性。这一节讲清楚我们是怎么把事件用稳的。

5.1 事件要表达业务事实，而不是数据操作

领域事件命名有个朴素但重要的原则：用过去时，表达业务事实。

不要用OrderUpdatedEvent，要用OrderPaidEvent、OrderRefundedEvent、UserLevelChangedEvent。因为监听方拿到事件，需要能立刻判断“发生了什么”，而不是再猜一次。OrderUpdated既可能是支付成功，也可能是地址修改，监听方被迫去查订单状态，等于把业务判断又请回来了。

事件内容放的是“业务快照”而不是指针。比如OrderPaidEvent携带订单号、用户ID、实付金额、商品类目、支付时间，订阅方不需要反向查询订单上下文，拿着快照就能做佣金计算，也方便后续审计。

5.2 Outbox模式：先落库再投递，事件才不会丢

如果发了消息之后业务事务回滚了，或者业务提交了但消息队列恰好宕机，都会出现“该来的事件没来”的局面。数据不一致就这么产生了。

我们的方案是Outbox模式。核心思路一句话：在业务所在的同一个数据库里，多写一张事件表，业务提交的同时事件也提交，再由后台任务把事件投递出去。

表结构大概是这样的：

CREATE TABLE outbox_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id VARCHAR(64) NOT NULL, aggregate_type VARCHAR(64) NOT NULL, aggregate_id VARCHAR(64) NOT NULL, event_type VARCHAR(128) NOT NULL, payload JSON NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0待投递 1已投递 2失败', created_at DATETIME NOT NULL, sent_at DATETIME NULL, UNIQUE KEY uk_event_id (event_id) );

投递任务的逻辑不复杂：定时扫描status为0的记录，逐条发送到消息队列，成功后把status改成1。发送失败的记录保留现场，人工或自动重试，方便排查。

有人会问，为什么不用分布式事务？原因很简单：分布式事务在跨数据库、跨消息队列的场景下成本高，而且容易拖垮性能。Outbox模式用“本地事务+异步投递”换来了可接受的一致性，对佣金结算这种对“事件不丢”要求极高的场景来说，是性价比很高的方案。

5.3 幂等与冲正：别让重复事件算两遍佣金

Outbox保证了事件不会丢，但消息队列投递的是“至少一次”语义，重复是常态。所以消费端必须做幂等。

我们的做法是：佣金明细表加业务唯一键，用event_id + order_id作为约束。重复事件到达时，插入被数据库拒绝，聚合根的addLineItem()里再配合一次存在性检查，双重保障。

退款冲正的逻辑也很重要。退款事件到达后，不是把原来的佣金明细删掉，而是生成一条金额为负的调整明细。这样做有三个好处：一是保留了原始佣金记录，审计能看到来龙去脉；二是佣金单总额通过冲正自然减少，逻辑一致；三是后续对账时，每一笔减法都有对应的事件依据。

还有一种更隐蔽的情况：本月佣金已经结算入账，次月发生退款。这时候不能去改本月已入账的资金记录，正确做法是在下个账期生成负数佣金，从新一期佣金里扣回。已入账记录已经和资金侧核对过了，动历史记录是大忌。

6. 落地过程中最想吐槽的三个误区

DDD落地翻车，通常不是概念难懂，而是容易陷入几个误区。我根据亲身经验列出三个最常见、危害最大的，帮你提前避坑。

6.1 为了DDD而DDD，把所有表都包成聚合根

见过一些团队，为了“展示DDD”，把用户表、订单表、日志表全部改造成聚合根。结果就是聚合根遍地开花，一次用户更新操作要跨四五个聚合开大事务，锁冲突、死锁频繁，性能反而比原来差。

聚合根不是“必须用”，而是“当你有业务不变量需要保护时用”。佣金单需要保护账平、幂等、可追溯，所以它是聚合根。用户表如果只是基本的增删改查，那就保持实体或查询模型，没必要硬包一层。

6.2 防腐层膨胀成“第二套上帝服务”

接了多个外部渠道后，防腐层很容易慢慢膨胀。开始是不同渠道的翻译逻辑，后来是渠道特有的风控判断、限流逻辑、状态机，最后变成一个谁也敢往里塞代码的地方。

防腐层的维护原则是：一个新渠道进来，只新增一个Adapter和一个Translator，不要修改已有渠道的翻译器；任何业务判断，一律回到领域层的领域服务或应用服务里判定。防腐层的代码应该是“稳定且薄”的，而不是“灵活而厚”的。

6.3 领域层贫血：包名是DDD，代码还是CRUD

最隐蔽的坑是包结构写得很规范，domain、application、infrastructure都建好了，但打开domain包，里面的类全是getter、setter、空壳构造，所有逻辑都堆在ApplicationService里。

判断标准很简单：如果把ApplicationService里的代码全部删掉，domain里还能剩下什么？如果什么都没剩下，说明领域层只是皮囊，业务规则仍然游离在服务层。

佣金单这个聚合根就应该自己会算总额、自己会拒绝非法退款、自己管状态流转。ApplicationService只负责两件事：从外部接收命令，调用聚合根的合适方法，然后保存结果。这才是真正的领域驱动。

最后说一个我自己很看重的落地细节：重构期间不要一次性把整个系统翻新。先选最痛、最经常出错的佣金结算模块下手，划清边界，设计好聚合根，然后保留旧的写入逻辑，用新事件并行跑一段时间的影子校对。每天跑一次对账脚本，把事件流水和佣金明细逐笔对齐，哪天不一致，就说明某个上下文越权了，当天就能定位。这个做法比“大爆炸式”重构稳得多，也是我整个项目推进中最值的一笔投入。