履约建模，共情、共利、共赢
在软件开发设计中，如何深入提炼业务，并获取业务方的信任，往往是困扰开发者的难题之一。由于对业务逻辑及运营（领域）逻辑的不明确，使得建立的业务模型不能有效地表达客户、合同、履约等要素之间的关联关系。从而导致构建系统时，无法有效和业务方同步业务知识，并导致业务侧对研发侧的不信任，不断试探研发侧的排期极限，最终导致再极其不合理的开发流程下，写出并不能令人满意的产品。
而 thoughtworks 中国区CTO徐昊老师总结沉淀的业务建模方法，称之为8X Flow建模法（我一般叫履约建模法，因为点名了切入点，下面都称履约建模法）。此方法能够有效的澄清、定义业务问题，进而总结、收敛业务逻辑复杂的系统。
概念介绍
履约建模法是基于权责体系的建模方法：是通过分析合同、参与方、参与方的履约职责（义务）与权利，帮助我们了解并建立业务模型的方法。简而言之，其就是一个通过合同中的甲方乙方逐渐理解业务并完成业务模型的过程。
详细了解
从履约理解业务
众所周知，企业在从事商业活动时，以合同作为支撑。通过合同界定参与方的义务及权利，保障及规范参与方的履约行为。同时，向相关监管、审计方提供商业活动中的履约凭证，以此证明商业活动的合法、合规、合理性。
在 B 端中，我们的合同上下文，是销售与客户之间的沟通桥梁。只有客户用上合同中的功能，才能正式的签单与付费。
在 C 端中，我们的合同上下文，则是我们一直忽视的“用户协议”（就是你登陆和付款时，看都不看的那部分），如果我们购买了视频网站的会员，但会员专属视频不能查看，那么我们就可以向 12315 举报。
上面的例子都是涉及到直接金钱交易的，但我们还有很多系统，不会涉及到金钱相关的内容。对于 CRM 系统，则是《劳动法》约束下的 kpi 协议，kpi 多次不达标则可以进行裁员。对于学校的选课系统，则是《中华人民共和国高等教育法》约束下的学生手册部分，只有拿到对应的学分，你才能拿到毕业证书。
既然业务方在基于履约上下文，来和客户进行交易，并养活整个公司，那么自然的，研发侧为了让履约成立，最合理有效的方式，就是完全拥抱业务视角，和业务一起，把履约上下文中的业务信息提取出来。并转化为模型和通用语言，以此建立双方的沟通桥梁。
合同的生命周期
对于大多数的合同的生命周期，主要可以分为：询价、报价、合同、履约四个阶段
- 邀请投标：你想做一个东西，谁可以做，怎么做，需要多少钱等都属于询价的过程。
- 投标：响应询价的过程。
- 合同：指合同的签订，是合同生命周期中最重要的节点，因为合同签订前的活动不具备法律效力，签订合同的节点才意味着真正产生法律效力。
- 履约请求：合同生效后，参与方对合同规定的义务及权利进行履约的过程。过程中会产生相应履约凭证，以此证明参与方履行了相关义务与权利。
- 履约确认：
举一个简单的例子：
在电子商务出现以前，家里也没网络和电脑的时候，我为了能够追上当时还在热播的“火影忍者”的进度，我一般会去寻找路边那些一身长衣下，埋藏了大量盗版影碟的摊主。
- 当我凑到摊主旁边问摊主火影怎么买，这时我（甲方）向摊主（已方）作出投标邀请
- 摊主把我拉到角落里回答说，两张碟 10 块钱，这就是投标。
- 作为从小到大的 i 人，我向来都是默认接受这个投标。
- 于是口头合同成立。我掏钱付款，完成支付履约；摊主提供货物，完成交付履约。至此业务执行完毕。
我们如果用 plantuml 进行建模，可以简单建模为如下：
- 从购买方角度来说，购买方有权要求售出方提供合理的商品，这个也是售出方必须承担的义务。
- 从售出方角度来说，售出方有权要求购买方交付合理的金钱，这个业务购买方必须承担的义务。
class 售出方 #yellow {}
class 购买方 #yellow {}
class 商品交易合同 #pink {
signed_at
price
}
class 商品 #green {}
'合同参与者
售出方 -- 商品交易合同
购买方 -- 商品交易合同
'要求给出对应的商品，权利方是“购买方”，义务方是“售出方”
class 商品提供请求 #pink {
start_at
expire_at
}
class 商品提供确认 #pink {
confirm_at
}
购买方 -- 商品提供请求
商品提供请求 -- 商品提供确认
商品提供确认 -- 售出方
商品提供请求 -- 商品
商品 -- 商品交易合同
'收到货物后进行打款，权利方是“售出方”，义务方是“购买方”
class 商品付款请求 #pink {
start_at
expire_at
}
class 商品付款确认 #pink {
confirm_at
}
售出方 -- 商品付款请求
商品付款请求 -- 商品付款确认
商品付款确认 -- 购买方利用现实合同理解业务
上面的例子，仅仅是一个线下的现金买卖业务，既没有第三方平台进行管控，也没有移动支付交易模块，显然是难以描述我们现实的软件业务流程的。接下去我们看一下转转的寄卖服务协议，是如何规定了参与方在商业活动中所要履行的一系列活动。 
划重点：现实建模过程中，需要和业务专家或者法务专家一起协作建模与纠正，像本文完全一个人做的建模结果并不能保证符合真实的业务
在这份协议中，其实包含了两个主要的合同上下文：
- “本平台”和“需求用户”之间寄卖合同上下文
- “本平台”和”购买方“之间的买卖合同上下文
首先我们来看寄卖合同上下文：“需求用户”并不会和”本平台“面对面签订合同，而是发起“寄卖单“作为合同。我们可以先建立合同的参与方：
'合同参与方
class 本平台 <role> #yellow {}
class 需求用户 <role> #yellow {}
class 寄卖单 <contract> #pink {
signed_at
}
寄卖单 "n" --o "1" 本平台
寄卖单 "n" --o "1" 需求用户接下去我们查看第一个履约项：“本平台”有权要求“需求用户”寄出合理的“二手商品”，这个也是“需求用户”必须承担的义务。
'合同参与方
class 本平台 <role> #yellow {}
class 需求用户 <role> #yellow {}
class 寄卖单 <contract> #pink {
signed_at
}
寄卖单 "n" --o "1" 本平台
寄卖单 "n" --o "1" 需求用户
class 二手商品寄出请求 <request> #pink {
started_at
expired_at
}
class 二手商品寄出确认 <confirmation> #pink {
confirmed_at
}
本平台 -- 二手商品寄出请求
寄卖单 "1" -- "1" 二手商品寄出请求
二手商品寄出请求 "1" -- "1" 二手商品寄出确认
二手商品寄出确认 -- 需求用户在上面中的 uml 图中，“二手商品寄出请求确认”的时间点是不能够随意定义的，只有在商品确实被寄出，产生快递单号后才可更新寄出商品时间点。我们要在上面增加"快递单"来作为“二手商品寄出确认”的追溯凭证。
'合同参与方
class 本平台 <role> #yellow {}
class 需求用户 <role> #yellow {}
class 寄卖单 <contract> #pink {
signed_at
}
class 二手商品 <thing> #green {}
寄卖单 "n" --o "1" 本平台
寄卖单 "n" --o "1" 需求用户
寄卖单 "1" -- "1" 二手商品
class 二手商品寄出请求 <request> #pink {
started_at
expired_at
}
class 二手商品寄出确认 <confirmation> #pink {
confirmed_at
}
class 快递单 <evidence> #pink {
created_at
}
本平台 -- 二手商品寄出请求
寄卖单 "1" -- "1" 二手商品寄出请求
二手商品寄出请求 "1" -- "1" 二手商品寄出确认
二手商品寄出确认 -- 需求用户
'二手商品寄出后，由快递单进行追溯
二手商品寄出确认 "1" -- "1" 快递单
快递单 "1" -- "1" 二手商品接着我们来看第二个履约项：从“需求用户”角度来说，“需求用户”有权要求“本平台”对“二手商品”进行检测，这个也是“本平台”必须承担的义务。
'合同参与方
class 本平台 <role> #yellow {}
class 需求用户 <role> #yellow {}
class 寄卖单 <contract> #pink {
signed_at
}
寄卖单 "n" --o "1" 本平台
寄卖单 "n" --o "1" 需求用户
class 二手商品质检请求 <request> #pink {
started_at
expired_at
}
class 二手商品质检确认 <confirmation> #pink {
confirmed_at
}
需求用户 -- 二手商品质检请求
寄卖单 "1" -- "1" 二手商品质检请求
二手商品质检请求 "1" -- "1" 二手商品质检确认
二手商品质检确认 "1" -- "1" 本平台namespace 寄卖合同上下文 {
'合同参与者
class 本平台 <role> #yellow {}
class 需求用户 <role> #yellow {}
class 寄卖单 <contract> #pink {
signed_at
price
}
class 二手商品 <thing> #green {}
寄卖单 "n" --o "1" 本平台
寄卖单 "n" --o "1" 需求用户
寄卖单 "1" -- "1" 二手商品
class 二手商品寄出请求 <request> #pink {
started_at
expired_at
}
class 二手商品寄出确认 <confirmation> #pink {
confirmed_at
}
class 快递单 <evidence> #pink{
created_at
}
本平台 -- 二手商品寄出请求
寄卖单 "1" -- "1" 二手商品寄出请求
二手商品寄出请求 "1" -- "1" 二手商品寄出确认
二手商品寄出确认 -- 需求用户
'二手商品寄出后，由快递单进行追溯
二手商品寄出确认 "1" -- "1" 快递单
快递单 "1" -- "1" 二手商品
class 二手商品检测请求 <request> #pink {
started_at
expired_at
}
class 二手商品检测确认 <confirmation> #pink {
confirmed_at
}
class 二手商品质检报告 <evdience> #pink {
created_at
}
需求用户 -- 二手商品检测请求
寄卖单 "1" -- "1" 二手商品检测请求
二手商品检测请求 "1" -- "1" 二手商品检测确认
二手商品检测确认 "1" -- "1" 本平台
'由检测结果来追溯追溯
二手商品检测确认 -- 二手商品质检报告
二手商品质检报告 -- 二手商品
}接下来我们看摘录自合同中的违约情况：
- 若需求用户邮寄商品与描述不符、超出二手商品范围或无法成功进行完整验机，本平台将有权与需求用户协商解决或选择直接终止寄卖委托并将二手商品通过到付方式回寄需求用户。
- 本平台在履行本协议的过程中，在对二手商品进行检测、寄存保管及向购买方交付过程中，应当保证二手商品的状态维持在接收时的功能正常状态，且无遗失、质量损毁情形（质检必然损耗、自然损耗、因七天无理由退货或协商退货导致的损耗除外）。如因本平台的操作、管理不当等过错行为，导致二手商品损毁，本平台应负责按照实际损失予以赔偿，且实际损失赔偿金额最高不超过需求用户确定的二手商品出售价格，若无出售价格则最高不超过寄出前的预估价格。