履约建模法
核心观点
8X Flow（履约建模法）把权责履约视为最小业务交互、把合同视为最小业务上下文，并用凭证、Request–Confirmation、违约履约和角色化确认揭示业务一致性、真实异步状态、系统边界与变化点。
方法定位
8X Flow 由四色建模法演进而来。四色建模强调从现金、KPI 与凭证追溯业务事实；8X Flow 继续追问这些事实处在哪一份合同中、证明哪一项权利或义务、失败后触发什么补救，以及不同合同和领域能力如何协作。
使用这套方法前，需要区分两类逻辑：
| 逻辑 | 主要特征 | 复杂度来源 | 适合的建模入口 |
|---|---|---|---|
| 业务逻辑 | 运营特定、领域中立 | 盈利方式、成本、合同、绩效和流程 | 合同、履约、现金、KPI 与凭证 |
| 领域逻辑 | 运营中立、领域特定 | 问题域自身的算法、计划、统计与优化 | 适合该问题域的对象模型或其他领域模型 |
业务系统利用领域能力赚钱或节省成本。把二者分开，既避免把运营规则误当作领域规律，也使业务上下文与领域上下文可以拥有不同的知识边界和弹性边界。
核心结构
- 合同上下文：聚合双方角色、正常履约、违约履约及相关凭证，是业务一致性的主要范围。
- 履约项：合同中一项明确的权利—义务关系，是最小业务交互。
- 履约请求（Request）：权利方向义务方提出主张，并给出履约时限；它表示一个时段。
- 履约确认（Confirmation）：证明义务已经履行的事实；它表示一个时点。
- 凭证（Evidence）：支持请求、确认、金额、时限或其他判断的可追溯事实。
- 角色与参与方：合同围绕双方角色建立；具体人或组织在合同中扮演这些角色。
- 标的物与领域上下文：合同引用的商品、内容、运力等领域概念，应放入相应领域边界，而不是塞进业务合同内部。
建模过程
- 寻找合同上下文，明确合同双方及其角色。
- 寻找合同中的主要履约项，标出每项权利方、义务方、履约时限和标的物。
- 对每个履约项使用四色建模法寻找请求、确认及其关键凭证，检查关键数据的来源和追溯关系。
- 对主要履约逐项追问违约情况；每种需要补救的违约都建立新的履约项。
- 对补救履约继续追问违约，直到进入合同外的法律处置边界。
- 将参与方和标的物划入相应领域上下文，区分业务逻辑与领域逻辑。
- 检查跨合同凭证引用造成的依赖；需要支持多种提供方式时，把履约确认角色化并反转依赖。
合同前业务与渠道上下文
合同签订前还没有履约项，但业务仍可按四个阶段展开：邀请投标、投标、合同签订、履约。与之对应的五类关键凭证是：
- 索取提案（Request for Proposal）：甲方发起需求或询价的时段凭证；
- 提案（Proposal）：乙方给出报价或方案的时点凭证；
- 合同（Contract）：双方约定成立的时点凭证；
- 履约请求（Fulfillment Request）：一方要求另一方在时限内履约的时段凭证；
- 履约确认（Fulfillment Confirmation）：证明履约完成的时点凭证。
合同前上下文只需保证最终合同可以追溯，不必与合同履约共享同一模型。实际业务中，同一合同可能由浏览、销售、代理、活动等多种渠道促成，因此合同前上下文是独立的渠道上下文，也是系统的重要变化点。
业务异步与一致性
Request–Confirmation 不是为了迎合消息队列而添加的技术结构，而是业务本身的异步结构：权利方提出主张后，在时限结束或确认到达前，履约处于尚未确定的中间状态。
履约失败也不应被技术系统静默“修好”。失败可能改变双方权责，因此应触发合同中已经约定的新履约项，例如退款、赔偿或重新交付；若补救继续失败，再进入下一项履约或法律程序。合同上下文通过正常履约和违约履约的组合维持业务一致性。
边界与变化点
- 合同上下文不等于弹性边界：同一合同中的支付、内容访问和退款可能有完全不同的容量与变更诉求；履约上下文才是更直接的弹性边界候选。
- 领域上下文拥有独立边界：领域逻辑以数据和问题域一致性为主，不应因业务运营方式改变而被迫同步变化。
- 渠道上下文是合同来源的变化点：合同履约无需知道合同究竟由哪一种渠道促成，只需保留必要追溯。
- 角色化履约确认是能力提供方式的变化点：当付款确认可由移动支付、预付余额等不同合同中的凭证提供时，让这些凭证扮演抽象确认角色，可以避免核心合同依赖每一种具体方式。
与其他方法的组合
事件建模法可以把 8X Flow 改造成共创工作坊：参与者沿邀请投标、投标、合同和履约时间线摆放凭证。事件风暴法提供参与和发散，四色建模提供凭证与数据追溯的收敛逻辑，8X Flow 则提供合同、权责、违约与变化点的结构。它们可以组合，但不是必须依次执行的固定阶段。
适用边界
- 对外交易可从正式或口头合同入手。
- 内部 CRM、销售管理或目标管理可以把绩效协议、KPI、OKR 和进度确认视为内部履约。
- 只提供商品、内容、算法等问题域能力的领域系统，应采用适合该问题域的领域建模方法。
- 单纯工具或集成胶水没有独立业务权责时，不应为了套用方法而虚构合同。
检验模型时，应让业务方用它解释主要履约、异常补救、凭证来源、跨合同协作和边界选择；解释不了的地方代表业务理解仍有缺口，而不是图画得不够完整。