别从实体开始：用事件、凭证和 8X Flow 理解业务建模

学 DDD 时，最容易混在一起的几个词是：业务、领域、事件、凭证、合同、履约、服务边界。

这些词都和“怎么设计系统”有关，但它们不在同一层。如果一开始没分清，后面很容易变成各说各话：业务方在讲流程，技术方在画类图，架构师在拆服务，最后大家都以为自己在做 DDD。

我现在更愿意把业务建模看成一条逐层推进的路径：

先区分业务和领域
再用事件展开业务过程
再用凭证链收敛关键事实
再找出支撑核心业务的业务脊梁
最后用 8X Flow 把合同、履约和变化点建出来

这篇文章用停车场收费业务做例子。停车场不复杂，但足够说明问题：它有车位、车牌、计费规则这些领域概念，也有收费、放行、月租、企业包年、结算、补偿这些业务逻辑。

先别急着列实体

很多建模讨论一开始就问：系统里有哪些实体？

停车场系统看起来很容易列：

车辆
车牌
停车场
车位
入场记录
出场记录
停车订单
计费规则
支付记录
会员

这些对象都可能存在，但只列名词没什么用。真正的问题是：它们为什么重要？哪个对象承载业务规则？哪个只是某个凭证的字段？哪个概念属于停车这个问题域，哪个概念来自停车场的运营方式？

如果只从对象开始，模型会很快变成一堆名词。名词多了，看起来很完整，但解释不了业务：

• 停车场为什么可以收费？
• 车主为什么必须付款？
• 支付后为什么可以放行？
• 费用算错时系统如何解释？
• 车辆已经付款但闸机没开，业务上算什么？
• 企业包年车、会员车、临停车是不是同一种合同？

业务建模要先问业务如何成立，再问对象如何组织。

业务和领域不是一回事

“业务领域”这个词很方便，但它会遮住一个重要差异：有些复杂度来自问题域本身，有些复杂度来自企业的运营方式。

我的理解很简单：

领域关注问题本身怎么成立。
业务关注如何利用这个问题域赚钱、省钱、履约和管理成本。

停车场里的领域逻辑包括：

• 如何识别车辆；
• 如何记录入场和出场；
• 如何计算停车时长；
• 如何根据计费规则算费用；
• 如何管理车位状态；
• 如何控制闸机放行。

这些逻辑和“这家停车场怎么赚钱”不是一回事。商场停车场、写字楼停车场、机场停车场都需要这些能力。

业务逻辑关心的是另一组问题：

• 临停车如何收费；
• 月租车如何签约；
• 企业客户如何包年采购车位权益；
• 商场消费抵扣如何核销；
• 无感支付和现金支付如何共存；
• 停车场和运营平台如何结算；
• 闸机故障导致无法出场时如何补偿；
• 值班人员如何考核巡检和人工放行记录。

同样是停车，不同运营方式会产生完全不同的业务模型。临停收费、月租包月、企业包年、商场停车券、无感支付，每一种都不只是字段差异，而是权责关系和凭证链的变化。

可以用两个问题粗略判断一个概念偏领域还是偏业务。

第一个问题：换一种赚钱方式，它会不会大变？

如果不会，大概率偏领域。比如车牌、入场记录、停车时长、计费规则。如果会，大概率偏业务。比如停车服务合同、月租协议、企业包年权益、停车券返现规则。

第二个问题：换一个问题域，这套逻辑还能不能复用？

如果能，大概率偏业务模式。比如预付费、包年服务、权益核销、平台结算。如果不能，大概率偏领域逻辑。比如车牌识别、停车计费、车位状态管理。

这个区分很实用。领域系统要按问题本身建模，业务系统要按运营、权责、履约和凭证建模。把二者混在一起，模型会越来越大，最后既不像领域模型，也不像业务模型。

事件把流程改写成事实

业务方讲流程时，通常会说：

车辆进场，系统开始计费，车主付款，闸机放行。

这是行为视角。事件建模会把它改写成一组已经发生的业务事实：

车辆已入场
停车订单已创建
停车费用已计算
停车费用已支付
车辆已出场
停车收入已结算

事件不是动作本身，而是动作完成后留下的事实。

行为	事件
车辆进入停车场	车辆已入场
系统按规则计费	停车费用已计算
车主完成付款	停车费用已支付
闸机完成放行	车辆已出场
财务完成对账	停车收入已结算

事件的价值在于，它刚好站在流程和模型中间。

业务方可以判断事件是否真实发生，技术方可以围绕事件继续追问：

• 谁触发了这个事件？
• 事件发生前需要什么条件？
• 它改变了哪个对象的状态？
• 它产生了哪些新信息？
• 谁会响应它？
• 它是否需要长期留存？

比如“停车费用已支付”这个事件，会引出停车订单、支付凭证、车主、停车场、应付金额、实付金额、支付渠道、放行策略等概念。

这就是事件建模比直接画类图更容易形成统一语言的原因。业务方未必能评审类图，但通常能判断“这件事是否真的发生”“发生后应该触发什么”“异常有没有漏掉”。

事件流的问题是太容易发散

事件流是按时间排列的一组事件：

车辆已入场 -> 停车订单已创建 -> 停车费用已计算 -> 停车费用已支付 -> 车辆已出场

事件风暴会通过工作坊把事件贴到时间线上，再找命令、行动者、策略、聚合和读模型。它的协作效果很好，因为业务方能参与发现事件。

但事件风暴有一个问题：发散容易，收敛难。

一场讨论里可能出现很多事件：

支付页已打开
车牌已识别
优惠券已选择
费用已刷新
停车费用已支付
闸机已抬杆
车辆已出场

哪些事件是关键业务事实？哪些只是交互事件？哪些要长期留存？哪些只是页面状态？

这些判断不能完全靠感觉。四色建模法的价值就在这里：不要只问“发生了什么”，还要问“哪些事实必须被证明”。

凭证链比事件流更接近业务

四色建模法也是事件建模方法，但它不是靠纯发散找事件。它从企业经营中稳定存在的东西入手：收入、支出、KPI，以及它们背后的凭证。

这里的凭证不是狭义的纸质单据，而是任何能证明业务事实的记录：

• 入场记录；
• 停车订单；
• 计费记录；
• 支付凭证；
• 出场记录；
• 发票；
• 停车券核销记录；
• 企业包年协议；
• 停车收入结算记录；
• 巡检和人工放行记录。

这些凭证不是随便记的。它们服务于权责证明。

车主付了停车费，停车场就要允许车辆离场。企业客户付了包年费用，停车场就要按约定提供车位权益。所以看到收入，要追问：

• 这笔钱对应什么权利？
• 停车场承担了什么义务？
• 履约成功靠什么证明？
• 用户质疑时系统如何解释？

支出也是一样。停车运营平台向停车场结算收入，就要证明停车场为什么有资格获得这笔钱，金额如何计算。公司向设备供应商付款，也要证明供应商交付了闸机、摄像头和维护服务。

没有现金往来的内部管理，也可以用类似方式分析。比如值班人员要按规定巡检，异常闸机要在规定时间内处理。管理者需要检查目标是否完成，员工也需要证明自己的工作产出。

这时凭证链可能是：

巡检目标已设定 -> 巡检记录已提交 -> 异常处理已确认 -> 月度绩效已确认

它不是交易，但仍然围绕目标、执行、检查、确认形成证据。

业务脊梁不是流程图

凭证链是一组可以相互追溯的业务证据。

停车收费的凭证链可以这样看：

入场记录 -> 计费记录 -> 支付凭证 -> 出场记录

它说明：

• 车辆什么时候入场；
• 停车时长如何计算；
• 费用依据哪条计费规则；
• 车主是否已经支付；
• 为什么允许车辆出场。

如果继续往前后扩展，就会得到业务脊梁：

停车服务规则 -> 入场记录 -> 停车订单 -> 支付凭证 -> 出场记录 -> 停车收入结算

业务脊梁是支撑核心业务运行的主凭证链。它不是普通流程图。

普通流程图记录操作：

车辆入场 -> 计费 -> 支付 -> 放行 -> 结算

业务脊梁追问证据：

谁和谁之间有什么约定？
金额由哪个凭证决定？
权利从哪个事实产生？
义务由哪个凭证证明完成？
结算依据是什么？
争议如何解释？

如果模型能解释下面这些问题，它才接近真实业务：

• 用户说费用算错了，系统能否解释？
• 入场时规则是 A，出场时规则是 B，按哪个算？
• 支付成功但闸机没开，如何追溯？
• 超时停留后是否补费？
• 会员折扣当时是否有效？

四色建模法真正有用的地方，是把建模从“找对象”推进到“找业务证据”。

8X Flow 把凭证放进合同履约结构

四色建模法已经能得到高质量凭证链。8X Flow 再往上走一步：它把凭证链放进合同和履约结构里。

如果说四色建模法关注：

业务事实如何被凭证证明？

8X Flow 进一步追问：

这些凭证属于哪个合同？
谁对谁有什么权利和义务？
履约如何发起？
履约如何确认？
违约后怎么办？
哪些地方是业务变化点？

8X Flow 里最关键的判断是：

权责履约是最小的业务交互。
合同是最小的业务上下文。

这里的合同不一定是纸质合同。订单、协议、用户条款、停车服务约定、口头约定、绩效协议，都可以看成合同上下文。

停车服务也是一个合同。车主有付款义务和停车、出场权利；停车场有收款权利和提供停车、放行服务的义务。

用 8X Flow 看停车服务

停车服务合同的参与方是：

车主 <-> 停车场

主要履约项可以是：

履约项	权利方	义务方
提供停车服务	车主	停车场
支付停车费用	停车场	车主
放行车辆	车主	停车场

每个履约项都可以拆成请求和确认：

停车缴费请求 -> 停车缴费确认
车辆出场请求 -> 车辆出场确认

这里有个观念很关键：履约失败不是简单的技术异常。

车主支付失败，停车场可以拒绝放行，或者继续计费。车主支付成功但闸机没有放行，可能触发人工放行、退款、补偿或设备故障处理。企业包年车辆识别失败，可能触发人工核验或权益修正。

这些都不是简单的 try/catch。它们会改变权责关系，需要凭证，也需要后续履约。

凭证角色化会暴露变化点

8X Flow 比四色建模更进一步的地方，是它能从业务结构里发现变化点。

看支付确认。停车服务合同真正关心的不是“微信支付成功”，而是“某种有效凭证可以证明车主完成付款”。这个支付确认可以由多种凭证扮演：

微信支付凭证
支付宝支付凭证
现金收款凭证
余额扣款凭证
企业账户扣款凭证
无感支付扣款凭证

如果模型写死“支付确认 = 微信支付成功”，每新增一种支付方式都要改核心停车业务。如果模型说“停车服务合同需要一个支付确认凭证”，不同支付方式只是扮演这个确认角色。

同样的变化点还可能出现在：

• 不同渠道生成同一种停车服务合同：现场入场、App 预约、企业白名单、第三方导航平台；
• 不同方式完成同一种放行履约：闸机自动放行、人工岗亭放行、无感出场；
• 不同计费规则完成同一种计费履约：临停、月租、企业包年、商场抵扣；
• 不同凭证确认同一种权益：会员车牌、企业授权、停车券核销。

这些变化点不是技术人员凭空设计的扩展点，而是业务结构本来就允许的替换关系。

这也是为什么 8X Flow 适合业务平台、中台和微服务边界设计。它能帮你看到：哪些东西是核心业务合同，哪些只是渠道，哪些是履约确认的不同实现，哪些领域能力可以被多个业务模式复用。

合同前上下文常常是渠道变化点

8X Flow 以合同为核心，但合同签订之前也有业务。

现实业务里，合同签订之前通常会经历：

邀请投标 -> 投标 -> 合同签约 -> 履约

日常场景也一样。

你去菜市场问：“这个怎么卖？”这是邀请投标。摊主说：“20 块一个。”这是投标。你说：“行，给我拿一个。”口头合同成立。你付款，摊主交货，进入履约。

停车业务里也类似：

• 查找附近停车场；
• 查看剩余车位；
• 比较收费规则；
• 领取停车券；
• 预约车位；
• 车牌识别入场。

正式入场或预约确认之前，这些都属于合同前上下文。只要停车服务合同还没成立，双方就还没有正式的权责约束。

这给架构设计一个很实用的提示：合同前上下文往往是渠道变化点。

同一个停车服务合同，可以来自现场扫码、车牌识别、App 预约、企业白名单、商场停车券、第三方导航平台。合同前流程可以千差万别，但最后只要生成同一种停车服务合同，后续履约就能复用。

中台建模也经常卡在这里。渠道可以变，合同和履约模式要尽量稳定。否则每接一个新入口，核心业务流程都要跟着改。

四色建模和 8X Flow 怎么搭配

四色建模法和 8X Flow 不是互斥关系。

它们的共同点是：都不是从对象出发，而是从权责出发。

区别在于：

方法	重点	适合解决的问题
四色建模法	通过收入、支出、KPI 追凭证链	把一个业务主链讲清楚
8X Flow	通过合同、履约、凭证角色化组织权责	把多个业务主链背后的业务模式和边界讲清楚

如果你刚开始建模，不要急着上 8X Flow。先用四色建模法把凭证链跑通。等你能解释“钱从哪里来、费用怎么算、权利如何产生、义务如何证明、争议如何追溯”，再把这些凭证放进合同和履约结构里。

这个顺序会顺很多。

什么时候推进到 8X Flow

四色建模法能把一个业务主链讲清楚，但它不一定要求你马上把合同上下文、履约上下文、服务边界都建出来。

是否推进到 8X Flow，我会看业务是不是已经从“单个流程”进入“业务模式和服务架构”的问题。

如果你要支撑多种停车业务形态，就应该考虑 8X Flow：

• 临停车；
• 月租车；
• 企业包年车；
• 商场消费抵扣；
• 会员权益停车；
• 第三方平台预约停车；
• 无感支付停车。

这些业务表面流程不同，但底层可能都在复用同一类停车服务合同：车主或企业获得停车权益，停车场提供停车和放行服务，费用通过不同方式确认。这个时候，问题已经不是“这条流程怎么跑通”，而是“能不能抽出一套可复用的业务模式”。

履约确认有多种实现方式时，也应该推进到 8X Flow。停车缴费确认可以来自微信、支付宝、现金、会员余额、企业账户、无感支付；车辆放行确认可以来自闸机自动放行、人工岗亭放行、异常补放行、无感出场确认。变化点越来越多时，只靠凭证链会越来越长，分支也会越来越多。

正在设计平台、中台或微服务边界时，更应该推进到 8X Flow。因为微服务边界不是“把系统拆小”，也不是“每张表一个服务”。服务要封装业务能力，有自己的产品化生命周期，编排层要尽量简单。

停车业务里，“查询停车订单表”不是业务能力，“完成停车缴费确认”“完成车辆放行”“完成企业权益核验”才更接近业务能力。

合同上下文可以作为服务边界候选。停车服务合同、企业包年合同、停车券核销协议、支付服务协议，各自聚合一组权责、履约和凭证。把合同上下文作为服务候选，至少能避免服务围绕数据库表拆出来。

履约上下文可以作为更细的弹性边界候选。车辆入场和出场放行可能是高频流量，收入结算可能是低频批处理，企业权益核验可能只在部分停车场或部分客户中出现。它们都属于业务履约，但容量、峰值、失败处理和生命周期不同。

领域上下文也可能成为独立能力。车牌识别、车位状态管理、计费规则计算、闸机控制，不一定直接属于某个合同，但会被多个业务合同使用。把这些领域能力从业务合同里分离出来，可以避免核心业务服务被设备细节、算法细节和集成细节拖住。

什么时候四色建模就够了

很多业务不需要一上来就推进到 8X Flow。

如果目标是澄清需求、理解主流程、找出核心凭证、验证异常场景，四色建模法通常就够了。

典型情况是：

• 业务还只有一个主要流程；
• 参与方不多，合同关系不复杂；
• 支付、放行、结算等履约方式比较固定；
• 还没有平台化、中台化或多前台复用诉求；
• 服务架构仍然是单体或模块化单体；
• 团队最痛的问题是“业务说不清”“规则散落”“异常无法解释”。

这时直接上 8X Flow 可能会过度建模。你会花很多时间讨论合同上下文、履约项、权利方、义务方，却连最基本的凭证链还没跑通。

更务实的做法，是先用四色建模法回答清楚：

钱从哪里来？
费用怎么算？
支付凭证是什么？
放行凭证是什么？
结算依据是什么？
出现争议怎么追溯？

如果这些问题都还没答案，先不要急着谈服务边界。

我的判断是：

四色建模法适合把一个业务主链讲清楚。
8X Flow 适合把多个业务主链背后的业务模式、权责结构和服务边界讲清楚。

不是所有系统都需要这套东西

业务系统适合用四色建模和 8X Flow。业务系统支撑运营，通常会留下合同、履约、凭证、绩效、审计痕迹。停车收费、会员、结算、企业采购、营销活动、绩效管理，都属于这一类。

领域系统要按问题域自身建模。停车管理、车牌识别、搜索、推荐、路径规划、图像识别，这些系统不一定直接涉及合同履约。它们可以用对象模型，也可以用规则模型、算法模型、统计模型。

工具系统不一定需要复杂建模。文件转换、简单配置后台、数据导入工具、设备调试工具，如果只是胶水代码，不必强行 DDD，也不必强行 8X Flow。

判断方法很简单：

• 它是否涉及收钱、花钱、结算、绩效、审计？
• 它是否需要解释权利和义务？
• 它是否会在争议中被拿出来证明某件事？
• 它是否存在履约失败后的补偿、取消、退款、罚息、人工介入？

如果答案经常是“是”，就应该认真做业务建模。

拿到一个业务怎么建模

我会按这个顺序来。

第一步，分清领域和业务。列出系统里的概念，逐个判断：它是在解决问题域自身问题，还是在支撑运营？换一种赚钱方式，它会不会大变？换一个问题域，它还能不能复用？它是否涉及合同、支付、结算、绩效、合规、审计？

不要把车位管理、车牌识别、路径导航、支付渠道、停车结算、绩效考核全塞进一个“领域模型”。

第二步，用事件流展开业务过程。把业务过程写成过去式事件：

车辆已入场
停车订单已创建
停车费用已计算
停车费用已支付
车辆已出场
停车收入已结算

先不要急着区分对象，也不要急着设计数据库。

第三步，用四色建模找凭证链。沿着收入、支出、KPI 三个方向追问：收钱后承担了什么义务？花钱后获得了什么权利？目标和实际结果如何证明？

对每个凭证都问四个问题：它证明了什么？关键数据项从哪里来？它会触发什么后续权利或义务？它能否解释异常和争议？

第四步，找业务脊梁。从所有凭证链中，找出最能解释核心业务模式的一条。不要把所有流程平铺，先抓主链：

停车服务规则 -> 入场记录 -> 停车订单 -> 支付凭证 -> 出场记录 -> 停车收入结算

业务脊梁抓住后，其他支线才有位置。

第五步，用 8X Flow 抽合同和履约。围绕业务脊梁追问：谁和谁之间有约定？合同上下文是什么？主要履约项有哪些？每个履约项的权利方和义务方是谁？履约请求和履约确认是什么？失败后触发什么违约履约？

如果找不到合同，通常有三种可能：你面对的是领域系统，不是业务系统；你面对的是工具系统，不需要业务建模；合同藏在组织分工背后，你还没追到业务源头。

第六步，找变化点和边界。重点看这些位置：

• 哪些履约确认可以由不同凭证扮演？
• 哪些合同前渠道可以生成同一种合同？
• 哪些履约项容量差异很大，可能需要独立弹性？
• 哪些领域能力被多个业务模式复用？
• 哪些支撑上下文不应该被核心业务直接依赖？

这些问题会自然导向服务边界、平台扩展点和中台能力。

结语

DDD 最开始吸引人的地方，是它说模型应该处在核心位置，业务语言、模型和代码应该关联起来。

但只讲“领域模型”还不够。现实业务系统的复杂度，很多不来自问题域本身，而来自运营方式：定价、支付、履约、违约、结算、绩效、渠道、审计、成本和法律风险。

事件建模让业务过程变成可讨论的事实。四色建模法让事件流从凭证和经营逻辑中收敛出来。8X Flow 再把凭证链放进合同履约结构里，识别业务模式、变化点和边界。

如果把它压成一句话，我会这样说：

领域说明系统处理的对象和问题是什么。
业务说明这些能力如何产生收入、控制成本和履行权责。
事件记录业务发生过什么。
凭证链证明这些事实为什么成立。
业务脊梁串起核心经营逻辑。
8X Flow 用合同和履约把这一切组织成可以演进的业务模型。

这比“系统里有哪些实体”更接近业务建模的起点。

真正落地时不用一步到位。单个业务主链先用四色建模法，把凭证链和业务脊梁跑通；当你开始面对多业务形态复用、渠道变化、履约确认多实现、平台化或微服务边界时，再推进到 8X Flow。