模式/组合工具/六步选型法

模式选型卡适合在讨论初期快速收束场景。准备进入开发或架构评审时，还需要回答更细的问题：当前方案到底哪里失效，两个模式在接缝处传什么，增加一个模式以后改善了哪项指标，又付出了什么代价。

六步选型法把这些判断排成一条证据链。每一步留下结构化产物，下一步只能使用已经记录的目标、事实和约束。负载、权限、模型、工具、数据或接口发生变化时，原有决策需要重新打开。

六步各自留下什么

贯穿示例：薪酬计划与结算事实发生冲突

考虑一次薪酬计算。公式服务首次调用超时，系统随后生成 payroll_plan v2，净工资为 9600 元。下游已经按这版计划形成正式结算事实和回执。此时，一个迟到的写入者又尝试把同一字段改成 9900 元。

9900 元是一项故障注入，用来检查已经越过交接边界的事实还能否被上游覆盖。这个场景需要局部恢复，也需要事实的单一写入权。规划执行与交接链分别处理这两个问题，但把两个模式接在一起时，仍可能产生双写。

1. 限定任务怎样才算完成

第一步暂不选择模式。团队先写清本轮判断：

• 公式服务超时后，未提交的薪酬计划可以局部修订。
• 结算事实一旦被下游接受，只能通过新版本和新回执更正，不能原地覆盖。
• 本轮验证不覆盖银行真实到账、跨系统分布式事务和密码学签名。

任务完成契约还要记录发起者、可信输入、运行环境、权限边界、外部结果、验收者和恢复规则。后续候选都在同一契约下比较，不能为了迁就某个方案临时改变目标。

2. 运行最小基线

基线可以只是一个共享可变对象。上游在其中写入 net_amount=9600，下游把它视为已提交。迟到写入随后把同一字段改为 9900。程序没有报错，结算含义却已经改变。

这次基线至少记录三项结果：

recovery_success = 0
committed_fact_overwrites = 1
settlement_receipts = 0

三个字段分别检查局部恢复、正式事实的覆盖次数和带版本回执。它们不评价方案好坏，只记录同一负载下发生了什么。

3. 把失败改写成约束诊断

每条诊断都要指向一项失败证据。模式目录到第四步才进场，避免先挑喜欢的模式，再为它补一个问题。

4. 生成少量候选组合

这个场景可以保留三组候选：

1. 共享对象基线：不增加模式，用作对照。
2. 仅交接链：保护事实所有权和版本回执，但不负责上游超时恢复。
3. 规划执行 + 交接链：payroll_plan 由规划执行拥有，提交前允许升版。settled_net_amount 由交接链独占生产，提交后只追加更正和回执。

候选中的每个模式都要对应前一步的诊断。没有对应关系的模式先不加入。

5. 先查接缝，再做对照与消融

模式单独成立，不代表接起来就成立。规划执行输出哪件工件，交接链消费哪个版本，谁拥有写入权，提交后能否修改，都要写入接缝契约。

artifact: payroll_plan
producer: plan_and_execute
consumer: handoff_chain
owner: payroll_planner
mutation_policy: versioned_before_commit
version_field: plan_version
acceptance: settlement_receipt

如果两个模式都声明自己可以改写 net_amount，候选在运行前就应被拦下。通过接缝检查后，再让基线和候选处理同一份超时负载。随后逐项拿掉规划执行、交接链或版本回执，观察哪项验收指标退化。消融用结果判断每个模式是否挣到了位置。

6. 写下裁决和重开条件

决策回执记录采用版本、被拒候选、指标变化、已知代价和责任人。薪酬示例可以采用“规划执行 + 交接链”的职责拆分版本，同时保留以下重开条件：

• 薪酬计划或结算事实的 schema 改变。
• 下游允许撤销提交，或更正流程发生变化。
• 权限边界、公式服务或交接接口换版。
• 新的生产负载出现当前实验没有覆盖的失败方式。

决策回执不是永久许可。重开条件让架构结论与当时的证据绑定。

可直接使用的记录结构

decision:
  id: payroll-plan-to-settlement
  goal: recover calculation without rewriting committed facts
  exclusions: [bank_settlement, distributed_transaction]

baseline:
  workload: formula-timeout-with-late-writer-v1
  failed_gates: [recovery, single_writer, versioned_receipt]

candidates:
  - id: handoff-only
    patterns: [C4]
  - id: split-plan-and-fact
    patterns: [A2, C4]

experiments:
  same_workload: true
  seam_checks: [owner, mutation_policy, version, acceptance]
  ablations: [remove_A2, remove_C4, remove_receipt]

receipt:
  decision: adopt_split_plan_and_fact
  external_acceptance_passed: true
  seam_tests_passed: true
  reopen_on: [schema_change, authority_change, interface_change, new_failure]

何时使用六步法

模式选型卡适合一次短讨论。六步法适合准备上线、包含写操作、需要跨团队评审，或组合中出现状态交接、循环、并行和委派的场景。一次性原型可以缩短实验，但仍应保留问题边界和完成条件。

已有参考架构可以缩短第四步。第二步和第五步仍不能省略，因为相同的模式组合换了数据、权限和负载，结果可能不同。

评审清单

1. 六步是否围绕同一项架构决策？
2. 基线和候选是否处理同一份输入与故障负载？
3. 每条约束诊断是否指向可检查的失败证据？
4. 每个候选模式是否负责一项已经观察到的缺口？
5. 接缝是否写明工件、所有者、版本、修改规则和验收方式？
6. 是否做了对照和逐模式消融，而非只测试最终组合？
7. 决策回执是否写明代价、责任人和重开条件？

相关资料

• ADPS 模式目录与选型框架
• 模式选型卡
• 常见模式组合