企业官网建设流程全解析

1. 三种建模到底是什么：先搞清楚它们各自解决什么

大概三年前，我在一次项目评审会上被问到"这个模块的建模怎么做"，结果产品、算法、后端三拨人各说各话，产品在讲订单状态怎么流转，算法在讲配送时长怎么预估，后端在讲服务怎么拆分，整场会开了两个小时也没对齐。从那以后我才真正意识到，"建模"这个词在不同人嘴里根本不是一回事——领域建模、数学建模、架构建模，名字里都带"建模"，但解决的问题、服务的对象、产出的东西，完全不同。

这篇文章就用一个贯穿始终的实例——外卖配送平台——把三种建模分别拆开讲一遍，再用同一个例子把它们串起来。适合的人群很明确：对软件工程有一定了解但概念容易混淆的开发者、刚入行的产品经理、以及写论文时需要做建模但搞不清楚该选哪种建模方法的同学。

1.1 三种建模的核心判断标准

要区分三种建模，不要从定义入手，要从"它回答什么问题"入手。

判断一个建模属于哪种，最直接的办法就是问自己：如果我拿着这个模型去找业务专家，他能看懂吗？如果他能看懂并确认"对，这就是我们的业务逻辑"，那是领域建模。如果这个模型是一组数学公式，业务专家看不懂，但算法工程师能据此实现一个调度算法，那是数学建模。如果这个模型画的是系统模块和服务依赖，只有技术人员能看懂，那是架构建模。

1.2 它们不是三选一，而是三个维度的投影

很多人会问：做项目时到底该做哪种建模？答案是：一个正经项目通常三种建模都需要，只是在不同阶段、由不同角色主导。

你可以把同一件真实世界的事看成一块不规则的多面体，三种建模都是对这个多面体的投影。领域建模投影的是"业务规则面"，数学建模投影的是"可量化计算面"，架构建模投影的是"技术实现面"。它们各自简化掉一部分细节，才能让特定角色专注解决特定问题。

明白这一点再往下走，就不容易把三种建模搅在一起了。下面用同一个外卖场景，把三套建模完整地做一遍。

2. 用外卖配送场景做一次完整的领域建模

现在假设我们要做的是一个外卖配送平台。业务不算特别复杂，但也足够典型：顾客逛商家、下单、支付、商家出餐、骑手取餐配送、顾客确认收货、平台结算。要做领域建模，第一步不是画图，而是把业务语言收集齐、定义清楚。

2.1 领域建模的产出物：业务词汇表与边界

领域建模的第一步是建立一份业务词汇表。这听起来很基础，但绝大多数项目不做，或者做得很随意，导致开发里的命名五花八门——有人叫"订单"，有人叫"单子"，有人叫"order"，还有人把"待支付"和"待接单"混在一起，一聊天就对不上。

我整理出的外卖平台核心词汇大致是这样：

• 顾客：下单、取消、支付、评价的主体
• 商家：上架商品、接单/拒单、出餐、发起退款的主体
• 骑手：接单、取餐、送达的配送执行者
• 订单：贯穿整个业务生命周期的核心实体
• 结算单：订单完成或取消后，平台与商家/骑手之间的财务记录
• 配送费：根据距离、时段、天气等因素计算出的配送服务价格

词汇一旦确定，后续的系统命名、数据库表名、接口字段名都应该尽量沿用这些词，不要另造新词。这是领域建模最容易体现价值的地方——它不是画几张好看的关系图，而是建立一套让业务和技术通用的"普通话"。

2.2 实体之间不是画线，而是建立"业务动词"

画实体关系图时，大部分人喜欢画方框和连线，但仅仅画出"顾客 下单 订单"这种箭头，信息密度太低。真正有经验的领域建模，会特别关注连线上那些动词，因为动词背后才是业务逻辑。

我还原一下外卖平台里最核心的几个业务动作：

• 顾客"创建"订单：订单初始状态是"待支付"，此时订单还不算真正生效。
• 顾客"支付"订单：支付成功后，订单状态变为"待商家接单"。
• 商家"接受"或"拒绝"订单：接受则进入"商家备餐"，拒绝则订单取消并自动退款。
• 骑手"接单"：接单后进入"待取餐"，骑手到店取餐后变为"配送中"。
• 顾客"确认收货"或系统"自动确认"：订单进入"已完成"。
• 订单"取消"：可以由顾客发起、商家发起、平台超时自动触发。

如果你只画实体和连线，你看不出这些状态约束；但你把动词写清楚，业务规则就浮出水面了。比如"取消"不是任何时刻都能做——已出餐的订单取消需要商家同意，已配送的订单取消会触达骑手和赔付逻辑。

这一步的实际产出，是一份带行为动作的领域图。领域建模面对的是业务语言，它关心的不是数据库外键，不是算法效率，而是"这个业务世界里，到底有哪些事会发生、按什么顺序发生、受什么条件限制"。

2.3 业务规则才是领域模型的灵魂

如果说词汇和实体是骨架，业务规则就是血液。同一个外卖平台，如果业务规则不同，领域模型会完全不同。

规则一：普通订单在下单后15分钟内可以无责取消，超时取消则要按距离收取违约金。这条规则直接影响订单状态机的设计——状态"待支付"和"待接单"必须区分开，否则无法判断取消的时机。

规则二：商家出餐超时20分钟，系统自动改派骑手，原骑手不再对该订单负责。这条规则会引出"改派事件""出餐倒计时""骑手与订单的松耦合关系"等设计点。

规则三：平台对超时送达的用户给予赔付，赔付金额由配送时长差值决定。这条规则会导致领域模型中增加"赔付单"实体，而且引入"预计送达时间"这个业务概念。

我见过不少团队做领域建模时就画四五个实体、几条连线，然后直接进入数据库设计，结果业务方一细问就漏洞百出。真正合格的领域模型，做完以后应该能拿给业务方看，让他用手在图上走一遍"下单到收货"的完整流程，并且挑不出毛病。这一步做到了，后面做数学建模和架构建模才有一块坚实的地基。

3. 同一场景下的数学建模：把"派单优化"做成可算的数字

领域模型让我们知道了业务世界有哪些要素和规则，但外卖平台的核心竞争力之一是"怎么把订单高效地派给骑手"。这个问题已经不是"有哪些实体"能回答的了，它需要数学建模：把配送效率抽象成目标函数和约束条件，然后设计可计算的求解方法。

3.1 从模糊目标到明确的目标函数

"派单要高效"这个说法没法计算。数学建模要做的第一件事，就是给"高效"一个可量化的定义。

常见的目标函数有两种选择：

1. 最小化平均送达时长，公式表达为：min (ΣT_i)/N，T_i代表第i个订单从下单到送达的时长，N为统计周期内订单总数。
2. 最小化超时率，也就是min (超时订单数/总订单数)，这会重点关注那批最危险的订单。

实际做派单策略时，通常不是只盯一个指标。更通用的做法是定义一个加权得分，比如：成本评分 = w1×预计配送时长 + w2×骑手空驶距离 + w3×预计超时惩罚 - w4×顺路奖励。

这里的w1到w4是权重，怎么定？不能拍脑袋，要靠历史数据回归或者人工设定后做AB实验。我一直觉得，权重参数的确定本身就是一个小型数学建模问题，它需要你定义清楚"时长、空驶、超时"这三者对业务损失的相对大小。

3.2 约束条件怎么量化

有了目标函数还不够，真实世界有一堆边界条件，也就是约束。数学建模如果不把约束写清楚，求出来的"最优解"在现实中根本不可行。

对外卖派单场景，我把常用约束列成了一张表：

约束不是越多越好，每加一个约束，求解难度都会上升。初学者做数学建模最容易犯的错，就是试图把现实中所有细节都塞进模型。技术上的正解是：先把最关键的3到5个约束放进模型，让模型先跑起来，再逐步增加约束，观察求解时间和效果变化。

3.3 可落地的求解思路与模型验证

外卖派单的数学模型，求解方法非常多，取决于规模。如果你只是做一个课程设计级别的Demo，用贪心分配就够了：每个新订单到达时，计算所有可用骑手的得分，把订单派给得分最高的那个，每30秒做一次批量滚动分配。

如果你要做一个稍微认真点的版本，可以把问题建模为带权二分图最优匹配：订单作为一侧节点，骑手作为另一侧节点，边权就是上面那个加权得分，然后用匈牙利算法或最小费用流求解。这种方法的优势是能考虑全局最优而不是单个订单局部最优。但需要注意的是，它要求订单和骑手数量都不能太大，否则计算时间会失控。

我实际做的时候，采取的折中方案是：先按商圈把骑手和订单分成若干组，每组内订单量控制在20以内，然后组内用匈牙利算法求解。这样既保证了实时性，又比纯贪心效果好。

模型做完必须验证，不能只在训练集上看数字。至少要做三件事：一是用历史数据回放，对比模型推荐方案和人工实际派单方案的送达时长；二是做仿真，把不同时段的订单流灌进模型，看超时率是否超标；三是小流量上线，拿真实业务AB测试。数学模型永远是现实的简化，没有经过真实数据验证的模型，再漂亮也只能停留在论文里。

4. 再把同一个场景做架构建模：系统怎么组织才能长期演进

业务规则搞清楚了，派单算法也想明白怎么算了，接下来才是技术人最熟悉的环节——架构建模。架构建模处理的不再是"业务怎么运转"，而是"系统在技术层面如何组织"。这一步做得好不好，直接决定这个平台后续加功能、扛流量、修故障的时候是轻松还是痛苦。

4.1 模块划分的出发点：领域边界与业务生命周期

架构设计最忌讳一上来就画微服务架构图。正确的做法是先回到领域模型，找到自然的业务边界。

在外卖场景里，我划分模块的依据有两个：一是领域模型里的核心实体和业务规则边界，二是业务生命周期的不同节奏。

按这个思路，外卖平台可以拆分为以下核心模块：

• 用户端服务：顾客注册、登录、地址管理、下单入口。
• 商家端服务：商家菜单管理、接单/拒单、出餐状态同步。
• 骑手端服务：骑手接单、取餐确认、送达上报。
• 订单中心：订单的创建、状态流转、取消与改派逻辑。这是整个系统最核心的模块。
• 派单引擎：承载上一章说的数学建模算法，输入订单和骑手位置，输出派单建议。
• 结算中心：配送费计算、商家结算、骑手佣金、赔付单处理。
• 营销中心：优惠券、满减、会员体系。这些逻辑和核心交易链路无关，独立成模块。

模块划分完，要关注的不是"我分了几个模块"，而是边界是否清晰。订单中心和结算中心之间，只通过"订单完成事件"通信，而不是让结算逻辑直接操作订单表。派单引擎不关心用户用没用优惠券，只关心"这单要从哪里送到哪里、什么时候能取到餐"。

4.2 依赖方向与数据流转的硬约束

架构建模中，模块间依赖方向是我每次评审必问的问题。好的架构，模块依赖应该形成单向的层次结构：上层可以依赖下层，下层绝不能反向依赖上层。

比如：用户端服务和商家端服务都依赖订单中心，但订单中心绝不能反向调用用户端服务去查"用户是否会员"。如果需要会员信息，应该由用户端服务把必要的身份信息带在请求里，或者订单中心通过事件订阅获得一份数据副本。

还有一条重要原则：能异步的不要同步。订单创建后，营销中心需要知道订单完成才能发积分、结算中心需要订单完成才能触发结算，但这些都不需要在下单请求的响应链路里完成。正确的做法是订单中心发一个"订单完成"事件，营销中心和结算中心各自订阅处理。这样即使结算服务临时故障，也不会影响用户下单主流程。

数据存储也需要建模。订单表的数据量会非常大，按订单ID分库分表几乎不可避免；派单引擎需要快速读写骑手实时位置，适合用缓存；结算数据对一致性要求极高，必须放在事务性强的存储里。架构建模要画出这些数据流，而不是只画几个方框表示模块就完事。

4.3 体量不同，架构建模的尺度完全不同

架构方案永远不能脱离规模谈。我见过不少团队照抄大厂的微服务架构，结果日订单量只有几千，服务拆了二十来个，连排查一个问题都要翻五六个系统的日志。

如果你服务的体量是日订单一千单，做单体应用加一个独立派单模块完全足够，连消息队列都可以省略，靠定时任务轮询搞定。如果日订单量到了十万级，那订单中心、派单引擎、结算中心就值得拆开了，引入消息队列做异步解耦也顺理成章。到了百万级，这时候你不仅要拆服务，还要考虑每个服务内部的读写分离、缓存策略、熔断降级、多活部署等，架构建模的深度和复杂度就完全不同了。

我做架构建模时有个习惯：先写清楚当前体量，再写清楚半年后的预期体量，方案至少要在设计上能支撑三倍增长。超出三倍的规划，不要提前做，因为业务形态随时会变，过度设计是架构腐化的第一根源。

5. 三种建模在同一个项目里的协作顺序与产物映射

到现在为止，三种建模在一个外卖平台上各自怎么做的已经讲完了，但实际项目中它们不是孤立开展的，而是有明确的先后顺序和承接关系。

5.1 推荐的建模顺序

我会用一个三段式流程，这也是我个人项目里反复验证过比较顺的顺序：

第一步，领域建模先行。目标只有一个：和业务方对齐"这个世界的运行规则"。这个阶段完全不考虑数据库、不考虑微服务、不考虑算法效率，只回答"业务上有什么、允许什么、禁止什么"。产出物是业务词汇表、实体关系、状态机、业务规则清单。

第二步，针对关键瓶颈做数学建模。领域建模做完，你会看到业务里最复杂、最需要决策的位置。对外卖平台来说就是派单和配送时长预估；对电商来说可能是库存分配和定价；对物流来说是路径规划。只有这些位置才值得动用数学建模，其他普通位置用简单规则处理就好。

第三步，用架构建模承接前两者。架构建模不是凭空设计，而是把领域模型里的边界翻译成技术模块界限，把数学模型的输入输出定义成算法模块的接口。领域模型里的实体和规则决定了模块怎么拆，数学模型决定了派单引擎的输入输出格式和性能要求。

这个顺序不能乱。我见过一个项目先画架构图，定好了服务边界，然后才去了解业务，结果发现订单状态流转和最初设计完全不一样，架构返工。先架构后业务，等于没看图就搭积木。

5.2 三种模型互相对照：产物如何映射到落地上

三种建模的产物绝不是相互独立的三份文档，它们之间存在清晰的映射关系。我把这个映射整理成了一张表：

拿"出餐超时改派"这一条举例你就明白了：没有领域建模，你根本不知道有"出餐超时20分钟自动改派"这条规则；没有数学建模，你不知道改派时该把哪些骑手列为候选、按什么打分；没有架构建模，你不知道"出餐倒计时"该由哪个模块维护、"改派指令"通过什么事件通道发给骑手端。三者一环扣一环，缺一个，整条链路就断掉了。

6. 最常见的混淆与自查清单

写到这里，把三种建模的概念、实践和协作关系都过了一遍。最后我想把过去几年见过的高频混淆集中说一遍，再给你一份动手前可以先自查的清单，能帮你省下不少开会吵架的时间。

6.1 常见混淆

第一种混淆，是把领域建模当成画数据库表。领域模型里的实体和数据库表有对应关系，但它们是两回事。领域模型里的"订单"包含业务行为和规则，数据库表只是它的持久化形态。如果你画领域模型时满脑子都是主键外键、索引、字段类型，你的图业务方一定看不懂，这个模型就失败了。

第二种混淆，是想用数学建模解决业务规则问题。有人问："订单取消规则怎么建模？"这本质是一个状态机规则描述问题，不是数学问题。它该用领域建模的状态图来表达，而不是套一个目标函数。数学建模只适合有"好坏程度可以量化"这类的决策问题，不适合"允许不允许"这类规则问题。

第三种混淆，是认为架构建模一步到位。架构不是画完一张大图就固定不变了，而是随着业务规模和技术演进而持续调整。日订单量一千的时候做微服务，十有八九是灾难，不是先进。架构建模要保持"演进的眼光"，但绝不是越复杂越好。

第四种混淆，也是最普遍的，是把三种建模放在同一个讨论里，互相绑架。我参加过的评审会里，产品拿着领域模型问"为什么这个服务不在左侧"，算法拿着数学公式问"为什么不按这个权重排序"，架构拿着部署图问"这个规则怎么没有在接口里限制"——每一项单独看都对，但放在同一个时空里谁也说服不了谁。明确讨论当下属于哪种建模，是我能给你的最实用的会议沟通技巧。

6.2 动手前的自查清单

无论你做的是哪种建模，动手之前都可以按这份清单过一遍。也不用全对，但至少要能回答其中大部分问题：

• 这个模型要解决的核心问题是什么？目标是否单一且明确？
• 谁会消费这个模型？他能否独立理解，还是必须由你解释才能看懂？
• 如果是对业务的建模，业务方能看懂并且会认可吗？
• 如果是对问题的数学描述，目标函数和约束条件是否都能被数据验证？
• 如果你是做架构，模块划分是否来自领域边界，还是拍脑袋分的？
• 模块依赖是单向的吗？有没有反向依赖？
• 方案里是不是塞进了当前根本用不上的复杂组件？
• 你能说出这个模型最简化的假设是什么，以及这个假设什么时候会失效吗？
• 模型是否预留了变化空间，而不是把所有细节都焊死？

拿这些问题去审视，很多建模方案其实撑不过半轮追问就会露馅。建模不是画图比赛，而是"为决策服务的抽象"——抽象对了，后面的开发、算法、运维都轻松；抽象错了，后面每一步都在还债。

我个人的做法是每次建模前先在白板左上角写一行小字，标明"本次是领域建模/数学建模/架构建模"，讨论过程跑偏了就指着那行字拉回来。看起来有点机械，但非常管用。建模这件事真正难的不是技巧，而是始终知道自己到底在解决哪一类问题。