企业官网建设流程全解析

1. 先想清楚：霸王餐到底是个什么业务

做了一年多霸王餐平台的订单和活动系统，我最大的感受是：这个业务表面简单，用领域驱动设计（DDD）一拆才发现里面的业务边界和聚合根全是讲究。所谓霸王餐，说人话就是商家拿出一部分套餐免费或者超低价让平台用户去吃，前提是用户吃完后要在平台留下真实评价内容。对商家来说是买曝光买口碑，对平台来说是把流量和评价盘活，对用户来说是免费吃饭加攒积分。听着是不是挺简单？可真要上系统，你会发现"免费"两个字背后挂着一整套资金、信用、核销、审核的规则。

我们系统当时已经长成了大家最熟悉的样子：activity表、apply表、order表、review表、refund表，五六张核心表互相外键，所有逻辑都写在三个大Service里。ActivityService负责发布活动和审核规则，OrderService负责下单、支付、核销、退款，ReviewService负责评价和内容审核。每个Service都是上千行，一个需求改完，另一个需求莫名其妙挂了。改活动报名规则，要动OrderService；改返款逻辑，ReviewService也要跟着改。责任边界完全糊了，没人能说清楚哪段逻辑到底该谁管。

这也是我当时决定用DDD重做核心链路的直接原因。这篇文章就聊两件事：霸王餐的业务边界到底怎么切，以及切完之后聚合根要怎么定。不写空泛理论，全是我在实际项目里拆分出来的方案和踩过的坑。适合正在做营销类、本地生活类平台后端，被"ddd搞不懂"卡住的朋友，也适合想从事务脚本往领域模型转的团队参考。

1.1 霸王餐平台的三方角色和核心链路

先把领域讲清楚，不然后面所有的边界和聚合都是空中楼阁。霸王餐平台表面上只有商家、用户、平台三方，实际上每一方内部还带着子角色。商家侧有门店运营者、财务人员；用户侧有普通会员、签约达人（内容质量要求更高）；平台侧有活动运营、内容审核员、客服、财务结算人员。一个核心链路走下来，每个角色关心的东西完全不一样。

核心链路拆开看是这样：商家创建霸王餐活动（设置名额、菜品、使用时间、参与条件）→ 平台运营审核 → 用户浏览活动并报名 → 平台抽签选中（中签）→ 中签用户下单并支付保证金（防止放鸽子不出现）→ 用户到店、核销、就餐 → 用户在平台提交评价和照片 → 平台审核评价 → 审核通过后退保证金、返积分、给商家结算。

这一条链路里，报名资格、中签概率、保证金规则、核销唯一性、评价审核状态、退款幂等，每一个词都是一个潜在的领域规则。把这一串名词的归属拆清楚了，业务边界自然就浮出来了。

1.2 为什么原来的"活动+订单"两张表撑不住了

我接手的时候，整个系统的数据模型是"活动中心化"的：所有业务都挂在activity这张表上，报名是activity的子表，订单是activity的子表，评价也是activity的子表。很多人觉得这很正常，一个活动下面挂报名、挂订单、挂评价，关系清清楚楚，查起来还方便。

问题在于这些子表之间会发生跨领域的规则碰撞。举个我真实遇到的例子：商家要做一个"新客专享"的霸王餐，要求用户必须从未在该店铺消费过。这个校验同时涉及用户消费记录、活动报名规则、订单状态三个领域，放在哪个Service都不对。又比如，活动创建的时候商家设置"男性用户不能参与"，这种规则写死在ActivityService里，等下一个活动又要"仅限女性"，又得改Service加字段。这就是典型的事务脚本：规则跟着操作走，业务对象没有自治能力，任何新需求来了都是给Service加一个if。

更难受的是状态流转没有约束。订单状态在Service里是int类型，谁都能set，业务上一个"已退款"的订单还能被另一个接口改成"已完成"。团队天天在代码里用一串状态判断互相兜底。DDD说的"聚合根保护不变量"，落到这里就是解决这类问题的：状态不是字段，是聚合根内部的状态机。

1.3 DDD在霸王餐场景里到底解决什么问题

DDD在这个场景里解决的核心问题只有三个。第一，把规则放回它该待的地方，让活动规则归活动管、订单状态归订单管、评价审核归评价管，而不是全部堆在Service里。第二，用限界上下文把六条业务线隔离开，改评价规则不影响订单链路的发布。第三，用聚合根保护关键不变量，比如核销唯一性、退款不能重复执行、报名不能超名额。

很多人一上来就纠结"我的表怎么设计"，这其实是反的。DDD的顺序是先切业务边界，再定聚合边界，最后才是库表结构。表结构只是聚合持久化的一种落地方式。换句话说，DDD不是新的建表方法论，而是一套"先划地盘、再定规矩"的领域建模方式。你只有把地盘划明白了，表和Service的归属才谈得上合理。

2. 业务边界怎么划分：别从表开始，从能力开始

2.1 从六条业务线里识别候选边界

我是用一个最土的办法起手的：把霸王餐的所有业务按"谁的问题"归类，不问数据关系，只问业务能力。最终得到六条相对独立的业务线。

第一条商家管理线：商家入驻、门店信息、营业资质、菜品维护。第二条活动营销线：活动创建、规则配置、审核发布、报名、抽签、中签。第三条用户会员线：用户账号、达人等级、信用分、行为标签。第四条交易订单线：下单、保证金支付、退款、幂等。第五条履约核销线：到店验证、核销码、就餐标记。第六条评价内容线：评价提交、图片上传、内容审核、展示状态。

这六条线的核心判断依据是：它们各自的规则变化频率和变化原因是否独立。商家管理线只看资质和门店，不会因为一个营销活动而改动；交易订单线只关心钱和状态，不在乎用户是霸王餐来的还是普通购买来的。规则变化的频率不同、变化的动机不同，就应该拆开。反过来，如果一个东西跟着主流程连动修改，那它和主流程大概率是同一个上下文。

2.2 用事件风暴逆向推边界

说到"ddd搞不懂"，大多数人是挂在"限界上下文"这个概念上。我的办法是别去啃定义，做一次事件风暴（Event Storming）就全明白了。做法很简单：拉上运营、产品、审核、财务各来一个人，在墙上贴便利贴，把所有业务事件按时间顺序贴出来，不用管先后对错，先把大家脑子里的事件全部掏出来。

比如霸王餐的完整事件流是：商家提交活动申请 → 运营审核通过 → 活动上架 → 用户提交报名 → 系统抽签生成中签名单 → 系统给中签用户发送通知 → 用户支付保证金 → 用户到店出示核销码 → 商家核销确认 → 用户提交评价 → 审核通过 → 系统原路退回保证金 → 商家收到结算单 → 商家确认或申诉。

事件风暴的价值在于：你贴完几十张便利贴，会发现"用户支付保证金"和"用户提交评价"之间隔着好几个不同的角色在操作，每个角色关心的事件不同，处理的规则也不同。能自然聚合在一起、由同一个角色连续操作的一组事件，往往就属于同一个上下文。比如"抽签"和"中签通知"是一组的，"核销码生成"和"核销确认"是一组的，"保证金支付"和"原路退回"是一组的。这三组彼此独立，就对应了三个不同的限界上下文。

2.3 限界上下文和上下文映射怎么做

我最后定下来的限界上下文是这七个：商家上下文（Merchant）、会员上下文（Member）、活动上下文（Activity）、订单上下文（Order）、履约上下文（Fulfillment）、评价上下文（Review）、结算上下文（Settlement）。每个上下文一个独立微服务模块（不一定独立部署，但至少独立代码模块和独立数据表）。

上下文之间的关系我用上下文映射图（Context Map）画了一遍。商家上下文和活动上下文是上游到下游的关系：活动上下文需要读取商家门店信息，但商家上下文的资质变更不应该打断进行中的活动。订单上下文和履约上下文是合作关系：订单上下文只管保证金支付，履约上下文负责核销，核销完成后通过领域事件通知订单上下文更新状态。结算上下文是典型的下游消费者，它监听评价审核通过事件、订单完成事件，自己算结算单，不回写别人的数据。

上下文映射的好处是让团队明确"谁依赖谁、谁听谁的"。活动上下文的改动可以通知订单上下文，但订单上下文绝不能反向改活动上下文的数据。这个约束一旦定死，团队改代码的时候就再也不会出现"顺手改了别人的表"这种操作了。边界不是用来画着好看的，是用来约束改动范围的。

3. 聚合根怎么找：一致性边界才是关键

边界切完了，接下来是大家最头疼的聚合根。我见过太多人把聚合根当成"表的主键"，这是最大的误解。聚合根不是表，它是一条业务规则的保护壳——一个聚合就是一组必须保持一致性的对象，聚合根是这个聚合的对外入口，是唯一能保证这些对象不被改坏的门神。

3.1 从实体与值对象开始找

找聚合根之前，得先把实体和值对象分清楚。实体是有唯一标识、会变化的业务对象，比如一个活动、一笔订单、一个商家。值对象没有独立标识，只有属性组合，描述事物的某个方面，比如金额、时间范围、核销码。

这个区分对霸王餐系统特别重要，因为里面有太多被当成实体其实是值对象的东西。比如"活动时间范围"（开始时间加结束时间）是值对象；"门店地址"（商圈加详细地址）是值对象；"保证金金额"（金额加币种）是值对象。如果在代码里把时间范围拆成两个字段，就会出现"开始时间被改了、结束时间没改"这种脏数据。把值对象建模成不可变类之后，这种问题从根上消失了。

我举一个很典型的例子，核销记录。很多人会把核销表设计成核销记录实体，带着id、订单id、核销时间、操作员。但仔细想，一个订单的核销行为本质上是订单状态的一次变迁，核销码的校验是订单聚合内的一个值对象行为。把它单独建模成实体，等于人为造出一个没有独立生命周期的东西，反而带来"订单核销了但核销记录没同步"的一致性问题。

3.2 四个核心聚合根的确定过程

先说结论，我最后定的四个核心聚合根是：活动（Activity）、报名（Enrollment）、霸王餐订单（FreeMealOrder）、评价（Review）。商家和会员虽然是实体，但它们更多是基础资料，各自独立成聚合，核心链路聚合不挂在它们下面。结算则是典型的事件驱动，不在核心聚合里做。

每个聚合怎么定的，我按理由说一遍。报名为什么独立成聚合而不是挂到活动下面？因为"一个用户只能报名一次"这个不变量，和"活动不能超过剩余名额"这个不变量，变化频率不同——用户提交报名是高并发写操作，如果报名是活动聚合里的一个集合，每次报名都要加载整个活动聚合，两千个人同时报名，活动聚合直接成了锁瓶颈。

订单聚合的边界要包括订单基本信息和状态流转，同时把核销码作为值对象放进来，保证"一个订单只能核销一次"。评价聚合包含评价正文、图片列表、审核状态、审核意见，评价提交后不允许用户直接编辑已发布内容，这个不变量由评价聚合自己保证。

3.3 聚合根代码长什么样

理论说完，上一段真实代码。这是FreeMealOrder聚合根的核心片段：

public class FreeMealOrder extends AbstractAggregateRoot<OrderId> { private OrderId id; private ActivityId activityId; private MemberId memberId; private Money depositAmount; private OrderStatus status; private CheckInCode checkInCode; private LocalDateTime paidAt; public void pay(Money amount, PaymentGateway gateway) { if (status != OrderStatus.CREATED) { throw new IllegalStateException("只有待支付订单才能支付"); } if (!amount.equals(depositAmount)) { throw new IllegalArgumentException("支付金额与保证金不一致"); } this.status = OrderStatus.PAID; this.paidAt = LocalDateTime.now(); registerEvent(new OrderPaidEvent(id, memberId)); } public void checkIn(String code) { if (!checkInCode.matches(code)) { throw new IllegalArgumentException("核销码不匹配"); } if (status != OrderStatus.PAID) { throw new IllegalStateException("未支付订单不能核销"); } this.status = OrderStatus.CHECKED_IN; registerEvent(new OrderCheckedInEvent(id, activityId)); } public void refund() { if (status != OrderStatus.CHECKED_IN && status != OrderStatus.PAID) { throw new IllegalStateException("当前状态不可退款"); } this.status = OrderStatus.REFUNDED; registerEvent(new OrderRefundedEvent(id)); } }

注意几个关键点：所有状态变更方法都要先校验当前状态，这就是不变量；状态流转只允许合法路径，比如核销必须发生在已支付之后；方法内部通过registerEvent发布领域事件，自己不关心发MQ的事。这样设计之后，任何想绕过状态机改订单状态的地方都没有入口，因为字段是私有的，外部只能调用pay、checkIn、refund三个方法。单元测试也特别省心，直接在JVM里跑，不需要Spring容器。

3.4 聚合划分的平衡：大了锁重，小了没边界

聚合的粒度是最难把握的部分。聚合越大，能保证的一致性越强，但并发能力越差、加载成本越高。聚合越小，并发和扩展性越好，但跨聚合的一致性只能靠最终一致去兜。

我在这个项目里踩过一个典型的大聚合坑。最开始我把活动、报名、中签结果全部放在Activity一个聚合里，想着这样报名校验简单，一条事务搞定。结果活动上线第一天，两千人同时点击报名，数据库锁等待直接打满，预约接口超时率超过30%。后来我把报名拆出去，Activity聚合只保留活动基础信息、状态和名额配置，报名聚合自己维护记录，通过领域事件异步更新活动侧的报名统计，并发问题立刻缓解了。

所以我的经验是：聚合边界的判断标准就一句话——如果两个业务对象必须在一个事务里保持强一致，才能满足业务规则的约束，那它们应该在一个聚合里；如果可以有短暂的不一致，靠补偿去兜底，那就拆开。这个判断标准比任何概念定义都管用，我之前也是绕了很久才想明白。

4. 实操：从一次霸王餐活动到订单全链路落地

前面讲的是设计思路，这一章把一条完整的霸王餐主流程从领域建模到工程代码走一遍，你可以直接照着这条路去推你自己的业务。

4.1 完整推演：发布活动到用户到店核销

我们以"某火锅店发布周末霸王餐活动"为例。第一步，商家在商家上下文提交活动创建指令：Activity聚合根创建，携带merchantId、活动时间范围、菜品明细、参与门槛、名额配置。第二步，运营审核通过，聚合根状态从DRAFT变为ONLINE，同时只存merchantId（不存整个Merchant对象），原因后面细说。第三步，用户报名，Enrollment聚合根创建一条报名记录，校验用户信用分达标、该用户未报名过此活动。第四步，抽签：报名截止后，抽签服务读取符合条件的所有报名记录，随机选中，调用报名聚合的win()方法把状态置为SELECTED，并发布ActivitySelectedEvent。

第五步，中签用户支付保证金，Order聚合创建，状态CREATED，支付成功后状态变为PAID。第六步，用户到店出示核销码，履约上下文调用Order聚合的checkIn()方法。第七步，核销完成后，Order聚合发布OrderCheckedInEvent，评价上下文监听到事件后，给用户创建一笔待评价任务。第八步，用户提交评价，Review聚合创建，状态PENDING。第九步，审核通过后，Review聚合发布ReviewApprovedEvent，结算上下文监听事件生成退款任务和商家结算单。

整条流程里，没有任何一个Service直接跨上下文修改另一个聚合的数据。所有跨上下文的动作都通过领域事件异步完成。这就是DDD在工程上真正的落地形态：聚合根负责保护和修改自己的数据，应用服务只做编排，领域事件负责跨上下文通知。

4.2 仓储与应用服务如何配合

聚合根的持久化通过仓储（Repository）接口完成。仓储在DDD里是一个抽象的存储边界，它只负责把聚合根整体取出和整体保存，不该写复杂的查询逻辑。这是仓储接口和它对应的应用服务的标准写法：

public interface FreeMealOrderRepository { Optional<FreeMealOrder> findById(OrderId id); void save(FreeMealOrder order); } public class CheckInApplicationService { private final FreeMealOrderRepository orderRepository; public void checkIn(CheckInCommand cmd) { FreeMealOrder order = orderRepository.findById(cmd.getOrderId()) .orElseThrow(() -> new OrderNotFoundException(cmd.getOrderId())); order.checkIn(cmd.getCheckInCode()); orderRepository.save(order); } }

应用服务做的事情只有三件：从仓储取出聚合根、调用聚合根的领域方法、把聚合根存回去。不写业务规则，不直接操作字段，不在应用层拼if-else。这也是检验代码是否DDD的一个简单标准：打开应用服务的代码，如果里面没有一行涉及状态判断和金额计算，说明规则都下沉到位了；如果应用服务里还有一连串的"if (order.getStatus() == ...) { ... }"，说明你的领域模型还没成型，规则还飘在上层。

4.3 模块拆分与工程结构

工程结构我按上下文拆成独立的Maven模块，每个模块内部再分四层。以订单上下文为例：

order-context/ ├── order-app/ # 应用服务、DTO、命令对象、查询服务 ├── order-domain/ # 聚合根、实体、值对象、仓储接口、领域事件、领域服务 ├── order-infrastructure/ # 仓储实现、事件发布实现、外部网关适配 └── order-interfaces/ # Controller、RPC接口、MQ消费者

domain层是整个模块的核心，它不依赖Spring、不依赖任何基础设施框架，只写纯Java。我把这个依赖规则定为铁律：domain层导入任何infrastructure的类，代码评审直接打回。这样做的好处是领域逻辑可以在不启动Spring容器的情况下用单元测试直接跑，比如上面那段FreeMealOrder的状态流转Tests，写纯JUnit就能跑完。

interfaces层是唯一允许出现Spring注解的地方，Controller负责参数接收和响应返回，不做任何业务判断。订单上下文的Controller里，每个接口的实现基本就是"调用一个应用服务方法"这么简单。这也是很多团队觉得DDD写起来"代码多"的原因——不是代码真的多了，是把以前堆在Service里的逻辑按职责放进了各自该待的层。

4.4 事务边界与最终一致性

DDD落地最容易被忽视的是事务。聚合边界决定事务边界：一个事务只对应一个聚合的变更。跨聚合的操作要么拆分多个本地事务，要么通过事件做最终一致。

在实际工程里我用两种模式配合。需要强一致的场景只在聚合内部，比如"订单核销时同时更新核销状态"这一个聚合的变更，直接一个本地事务就够。跨上下文的场景全部用事件驱动：核销完成后发布OrderCheckedInEvent，评价上下文接到事件后创建评价任务，结算上下文等评价审核通过再退款。评价上下文和结算上下文各自是独立事务，失败了自己重试，不阻塞主链路。

这里有个常见失误：有人图省事，在一个事务里同时修改Order和Review两个聚合的数据，还拉着它们的外键。这等于人为制造跨上下文强一致，让两个独立演进的上下文被数据库锁绑在一起。一旦评价审核规则改了、订单表反过来受影响，你就又回到了最初那个"改一个需求动五个类"的老路。事务边界这件事，必须在设计评审的时候当红线来定。

5. 常见问题与避坑实录

这一章把我实际踩过的问题和团队里被问得最多的问题集中整理一下，每条都是我真实处理过或者观察到的，不是从教程里抄的。

5.1 聚合根之间到底用ID引用还是对象引用

这是DDD社区老生常谈的问题，我直接给结论：聚合根之间用ID引用，聚合内部用对象引用。理由有两条。第一，聚合根的生命周期相互独立，如果你在订单聚合里直接持有Activity对象，每次加载订单都要连带加载活动，活动改个名、改个状态，订单聚合的缓存就全失效了。第二，用ID引用在并发和一致性上更干净：订单持有activityId，只是标识关联关系，不构成跨聚合的对象图。

聚合内部则完全不同。订单聚合里的核销码、金额、时间段，必须是强类型的值对象引用，不能退化成String和Long散落在字段上。你宁可多写几个类，也不要把核销码、状态、时间这些语义丢进一个Model里。值对象的好处是它能把校验逻辑内聚起来：核销码这个类自己验证格式、自己判断匹配，订单根根本不需要知道核销码的生成算法。

5.2 跨聚合的"伪需求"怎么处理

很多人在实践中会碰到这类需求："要把订单列表和评价一起展示在管理后台"，于是第一反应是让Order聚合直接关联Review聚合，或者写一个大查询join两张表。这个需求其实是展示需求，不是领域规则需求。管理后台的聚合查询，正确的做法是走独立的查询模型（也就是CQRS里的读模型），专门建一张宽表或者用一个查询服务去拼数据，而不是去改聚合根之间的关系。

我做过一个类似的优化：订单列表页面最初直接查订单表，然后每行再查一次评价表，接口响应时间从300毫秒涨到2秒。后来我建了一个order_review_read_model宽表，评价审核通过后通过事件更新宽表，查询接口稳定在60毫秒以内。这个经验的核心是：把写模型和读模型分开，聚合根只服务写侧规则，读侧用专门的数据结构，别让查询需求倒灌进聚合设计。

5.3 新手搞不懂DDD通常卡在哪三个地方

"ddd搞不懂"这个问题我回答过很多次了。总结下来，新手普遍卡在三个地方。第一个是概念混淆：分不清实体和值对象、聚合根和实体、领域事件和消息队列。我建议先别背名词，先把聚合根画出来、把状态流转写出来，再回头对照概念，你会发现"原来值对象就是没有id的不可变类"这种事，一句话就能想通。

第二个是过度设计：很多团队一上DDD，就把十几个表全拆成一堆类，还搞七八个上下文，代码量翻倍，效率反而下降。DDD是要给核心业务域用的，不是给每一个CRUD都套上领域模型的。如果你的业务规则简单到"就是把一条记录增删改查"，直接用事务脚本，别硬凹。

第三个是分不清该在什么时候用DDD：DDD适合业务规则复杂、状态流转多、多人协作频繁改规则的系统，比如交易、营销、履约、结算这种。对于纯粹的展示型、报表型业务，用不用DDD没有本质差别。判断标准是：如果需求改起来经常涉及多个模块的联动修改，那就是边界切错了，DDD能在前期帮你发现这个风险。

5.4 一点经验总结

最后说点我个人体会。DDD这个架构方法论，它真正值钱的地方不是那些概念和模式，而是它强迫你在写代码之前，把业务规则想清楚、把一致性边界想清楚、把模块依赖想清楚。霸王餐这个项目做完以后，我最大的变化是：再遇到任何系统，我第一反应不是去看表结构，而是去问"这个业务的规则变化，是围绕哪个对象、在什么地方发生的"。

如果只能给一条建议，我会说：别想着一口气把所有上下文都建模完。先用事件风暴把核心链路贴一遍，找到最痛的那一段——比如你们改得最频繁、出bug最多的那块——先做DDD改造，跑通了再推广。DDD从来不是一次重构就能完成的工程改造，它是一个不断把规则归位的过程。规则归位了，边界自然清晰；边界清晰了，聚合根就不是什么玄学问题。