业务建模流程

Difficulty: Intermediate
Status: Stable
Last reviewed: 2024年9月

“业务建模”和“DDD 领域设计”不是两个割裂步骤。通常先理解业务，再通过 DDD 将业务知识沉淀为领域边界、模型和代码。

完整过程

1. 还原业务流程

先不讨论表结构和接口，而是和产品、财务、业务人员梳理：谁参与业务、在什么场景下发起、经过哪些状态、有哪些业务规则、最终产生什么业务结果。

例如盘古业财链路：

订单履约完成
→ 生成应收
→ 客户付款
→ 创建收款单
→ 财务审核
→ 收款核销
→ 更新应收余额
→ 推送财务系统

2. 统一业务语言

明确“应收、收款、核销、清分、预收款”等概念，避免不同团队对同一个词理解不同。

概念	定义
应收	客户应该支付的金额
收款	企业实际收到的资金
核销	将收款金额与应收账款进行匹配
清分	按照客户、供应商或平台规则拆分资金

3. 划分领域边界

根据业务职责和变化原因划分限界上下文，而不是按数据库表拆服务。

盘古可以划分为：

领域	职责
收款域	应收、收款、核销、预收款
付款域	应付、付款申请、预付款
清分域	清分单、清分匹配、资金拆分
财务适配域	将履约事件转换为财务数据
财务集成域	对接 FSSC、金蝶等外部系统

4. 设计领域模型

在每个领域中识别实体、值对象、聚合根、领域服务、领域事件。

例如“应收聚合”：

类型	内容
聚合根	应收账款
实体	应收明细、核销记录
值对象	金额、业务来源、账期
业务行为	核销、冲销、调整
领域事件	应收已创建、应收已核销

5. 把业务规则放进模型

领域模型不能只是数据库对象加 getter/setter，需要封装业务约束：

核销金额不能超过应收余额
已完全核销的应收不能重复核销
已作废收款单不能参与核销
同一业务单据不能重复生成应收

6. 设计领域间协作

聚合内部采用事务保证一致性；跨领域尽量通过领域事件和消息实现最终一致性。

WMS 发布"出库完成"事件
→ 财务适配域判断是否需要生成应收
→ 收款域创建应收账款
→ 发布"应收已创建"事件
→ 财务集成域推送 FSSC

面试表达

我做业务建模时，首先会和产品及业务人员梳理角色、业务流程、状态变化和核心规则，并通过统一语言明确应收、收款、核销、清分等业务概念。

然后按照业务职责和变化原因划分限界上下文。例如在盘古业财中心，将系统拆分为收款、付款、清分、财务适配和外部财务集成等领域，而不是简单按照数据库表拆分服务。

在领域内部进一步识别聚合根、实体、值对象和领域事件，把核销金额不能超过应收余额、业务单据不能重复生成应收等规则封装在领域模型中。领域内部通过事务保证一致性，领域之间通过 RocketMQ 和领域事件解耦，最终形成从订单履约、应收应付生成到收付款和财务系统同步的完整业财链路。