一种以业务履约关系为视角,通过提取业务模式并引入变化点构建可复用业务模型的,云原生时代的业务建模方法

你现在是一名资深的业务架构师,擅长使用履约建模法分析复杂的业务场景。请根据我提供的“业务场景”,严格遵循“履约建模法与思维链”的指导,完成指定的“任务”。

业务场景 (User Story)

作为一名专栏平台的用户,我希望能够购买一个付费专栏。在下单后,我需要在15分钟内通过移动支付完成付款。付款成功后,我期望平台能够立即为我开通该专栏的阅读权限。如果专栏后续发生长时间断更,我希望能得到全额退款。

履约建模法与思维链 (Modeling Method & CoT)

通常一个完整的业务过程都存在 5 个关键阶段,以及每个阶段的业务凭证(Evidence)。

  • 索取提案(Request for Proposal):凭证如商品询价单,代表的是时段
  • 提案(Proposal):凭证商品报价单,代表的是时刻
  • 合同(Contract):凭证如商品采购协议、订单,代表的是时刻
  • 履约请求(Fulfillment Request):凭证如支付申请单,发票开具申请,发货申请单,代表的是时段
  • 履约确认(Fulfillment Confirm):凭证如支付确认单,发票开具确认,发货确认单,代表的是时刻

履约建模法图例:

  1. 凭证(Evidence)使用粉色标识。有以下几种类型
    • 索取提案(Request for Proposal):表示发起索取提案的过程,用于留存其发起证据的业务凭证。在图例中使用 rfp 标识。
    • 提案(Porposal):表示发起提案过程,用于留存其发起证据的业务凭证。在图例中,用 porposal 标识。
    • 合同(Contract):表示当事双方形成正式合同关系,用于留存器合同签订证据的业务凭证。在图例中使用 contract 标识。
    • 履约请求(Fulfillment Request):标识某一当事方发起履约的过程,用于留存其履约发起证据的业务凭证。在图例中使用 request 标识。
    • 履约确认(Fulfillment Confirm):表示某一当事方在履约过程中实施了某种履约确认,用于留存其履约确认的业务凭证。在图例中使用 confirm 标识。
    • 其他凭证(Evidence):表示任何不属于前 5 种类型的,但为了追溯需要而必须留存证据的其它业务凭证。在图例中使用 evidence 标识。
  2. 参与元素(Participant)使用绿色标识。
    • 当事人(Party):履约过程中所涉及到的具体人员(或其在系统内的对应存在),对凭证所承载的权责直接负责(也可以理解为凭证需要谁签字或盖章)。在图例中使用 party 标识。
    • 标的物(Thing):履约过程中,会涉及到凭证相关的非凭证物品(往往是交易或履约的具体对象)。在图例中使用 thing 标识。
  3. 角色(Role)使用黄色标识
    • 当事人角色化:从合约的角度上来讲,合约的当事双方实际上都是法人,而具体的当事人实际上是在业务流程中代表法人进行履约活动。需拟人化命名,使用 party 标识。当事人和对应的角色,是两个独立的概念。
    • 履约确认角色化:有时候履约确认凭证,是其它合同上下文提供的。比如订单确认的凭证,需要支付平台的支付凭证提供。如果履约确认凭证,可以由多种合同上下文提供,则需要角色化,需要将原本的粉色标识,改为黄色标识,使用 confirm 标识。
  4. 上下文(Context)
    • 未表明扮演关系的参与元素、领域逻辑、第三方系统和其它合约上下文均处于独立的上下文中
    • 参与元素、领域逻辑、第三方系统,通常是专门的领域问题,业务逻辑与领域逻辑的边界清晰分离
    • 在无需通过抽象提供变化点的情况下,可能与另一个合约上下文中的时刻类凭证进行跨上下文的直接关联、
    • 在通过抽象变化点的情况下,通过角色化元素和时刻类凭证的扮演关系进行跨上下文的直接关联
    • 两个合约上下文,可能通过对于某个使用的参与元素及所属的领域上下文产生间接关联。

使用履约建的思维链(Chain of Thought)步骤如下:

  1. 寻找合同上下文,明确合同的参与方;
  2. 寻找合同中的主要履约项,按四色建模寻找凭证;
  3. 对于主要履约项,寻找违约情况,设立新履约项,按四色建模寻找凭证;
  4. 重复步骤 3,直到不得不打官司为止;
  5. 将当事人和标的物划分入领域边界。

其中,四色建模寻找凭证的流程是:

  1. 寻找现金往来,构造一个凭证表示。在凭证上罗列发生的时间点、金额等关键数据项。
  2. 针对每一项关键数据项目,寻找来源。来源只能由三种:用户输入、由前序凭证提供、算法计算
  3. 回到现金凭证,思考它所对应的权利与责任。这些权利与责任需要哪些凭证证明,并以此为依据,寻找后续凭证。
  4. 无论是何种凭证,必须罗列关键数据项,并保证数据项获取的顺畅。
  5. 如果和现金往来关联不大,那么寻找关键 KPI 指标,并构造一个验收凭证表示它。其余步骤和现金往来一致。
  6. 获取了相互关联的凭证流(事件流)以后,进入模型细化阶段,围绕每个凭证,寻找参与其中的角色。
  7. 思考哪些参与方可能扮演这些角色,并将他们加入模型中

任务 (Task)

请根据上述“业务场景”,并严格遵循“履约建模方法与思维链”,提取场景中的核心业务概念,并完成以下要求:

  1. 识别出场景中的所有能找到的合同上下文,。
  2. 以表格形式输出每一个合同上下文的概念字典 (Glossary)
  3. 在表格中包含三列:概念名称(附带英文)使用哪种图例概念定义