implementation-approach

实施策略选择框架（元认知方法）

元认知策略选择流程

阶段 1：决策充分的当前状态分析

核心问题：“现有实现是什么样的？”

分析框架

Architecture Analysis: Responsibility separation, data flow, dependencies, technical debt
Implementation Quality Assessment: Code quality, behavior-relevant test evidence, performance, security
Historical Context Understanding: Current form rationale, past decision validity, constraint changes, requirement evolution

元认知问题列表

• 此实现的真正职责是什么？
• 哪些部分属于业务本质，哪些部分源于技术约束？
• 代码中有哪些依赖关系或隐式前提尚不明确？
• 当前设计带来了哪些好处和约束？

如果进一步了解当前状态的事实已无法改变职责、复用方式、选项有效性、总体复杂度、契约或验证方式，就停止分析。

阶段 2：设计收敛

选择实施策略前，按顺序完成以下步骤：

1. 现有表面基线：通过现有职责，构建能够实现当前结果的最简单端到端路径。明确要求和已接受的决策具有约束力；建议采用的机制仍属于候选方案。
2. 证据检查：根据当前要求、已验证的约束、观察到的范围内问题，以及有证据支持的实质风险，检验该路径。仅保留可能改变所选设计的未满足条件。
3. 有针对性的比较：针对每个未满足条件，在扩展设计表面之前，先检验复用、从现有数据推导、按需计算，或由当前调用方或边界承担职责等方案。按总体复杂度比较可行方案，比较实质不同的维度：用户决策、设置、模式、概念、输出、持久化状态、实现路径、用户体验、运行时、实现、测试、文档和维护。选择满足该条件且总体复杂度最低的方案。
4. 删减检查：移除每项拟议的新增内容，并重新检验其所针对的条件。仅当移除后，已确认的结果、必需的边界或必要的证明会无法满足时，才保留该项。

将支持性论据归类为已观察、推断或未知。如果未知信息会阻碍下一步，则将其列为具体的证据前置条件；是否需要用户交互，由调用方的价值边界和不可逆操作关卡决定。

候选路径和被否决的新增内容仍属于有效分析的一部分。持久化输出是选定设计：完整的选定路径，以及每项新增设计表面的证据和移除该项后无法满足的条件。已接受的 ADR 可以将备选方案保留为决策历史。实施者使用相同的收敛检查，但无需生成单独的产物。

阶段 3：策略探索与制定

核心问题：“在确定从之前到之后的变化时，应参考哪些实现模式或策略？”

策略发现流程

Direct Strategy: Smallest repository-supported change that satisfies the accepted requirements and constraints
Repository Alternatives: Existing patterns that materially differ in migration, dependency order, or verification boundary
External Research: Official/current sources only when repository evidence cannot resolve a time-sensitive capability, compatibility, or dependency decision

参考策略模式

旧系统处理策略：

• 绞杀者模式：通过分阶段替换逐步迁移
• 外观模式：通过统一接口隐藏复杂性
• 适配器模式：与现有系统进行对接

新开发策略：

• 功能驱动开发：采用垂直实现，优先实现用户价值
• 基础驱动开发：优先构建基础，强调稳定性
• 风险驱动开发：优先处理风险最高的要素

集成／迁移策略：

• 代理模式：透明地扩展功能
• 装饰器模式：分阶段增强现有功能
• 桥接模式：通过抽象实现灵活性

仅当存在与这些模式名称相对应的迁移问题或依赖问题时，才使用这些模式。从直接策略开始。如果某种替代方案会实质性地改变风险、推出方式、兼容性或早期验证节点，则将其纳入比较。仅保留能够带来此类实质差异的选项。

阶段 4：重大风险评估与控制

核心问题：“将此方案应用于现有实现时会产生哪些风险？最佳控制方式是什么？”

仅评估当前证据可能改变策略、公开契约、发布、回滚或验证边界的风险类别。

条件性风险类别

Technical Risks: System impact, data consistency, performance degradation, integration complexity
Operational Risks: Service availability, deployment downtime, process changes, rollback procedures
Project Risks: Schedule delays, learning costs, quality achievement, team coordination

风险控制策略

Preventive Measures: Phased migration, parallel operation verification, integration/regression tests, monitoring setup
Incident Response: Rollback procedures, log/metrics preparation, communication system, service continuation procedures

阶段 5：与决策相关的约束兼容性

核心问题：“本项目有哪些约束？”

仅检查有依据的约束，这些依据来自主导要求、代码仓库、外部契约或当前环境，且约束可能改变所选策略或验证边界。

条件性约束类别

Technical Constraints: Library compatibility, resource capacity, mandatory requirements, numerical targets
Temporal Constraints: Deadlines/priorities, dependencies, milestones, learning periods
Resource Constraints: Team/skills, work hours/systems, budget, external contracts
Business Constraints: Market launch timing, customer impact, regulatory compliance

阶段 6：实施方案决策

选择与已验证的依赖和交付约束直接匹配的实施方案：

垂直切片（功能驱动）

特点：按功能单元跨所有层进行垂直实现 适用条件：默认采用，前提是能够独立交付和验证端到端的价值单元。数据模型共享和层级广度是辅助依据，不能替代独立交付能力 验证方法：每项功能完成时验证终端用户价值交付

水平切片（基础驱动）

特点：按架构层分阶段构建 适用条件：当公共基础阻碍使用方工作，或必须先通过稳定性／兼容性验证才能开展依赖它的切片时采用。多个使用方实质性地共享依赖所有权，是评估此方案的信号 验证方法：所有基础层完成后验证集成运行

混合方案

特点：根据项目特点灵活组合 适用条件：当必须先完成经验证的基础步骤，而后续工作可以作为可独立验证的价值切片推进时采用。选择实施方案前，先解决阻碍工作的需求歧义 验证方法：根据各阶段目标，在适当的 L1／L2／L3 级别进行验证

阶段 7：记录决策依据

在适用的实施或设计决策记录中记录：

1. 所选策略的名称和特点
2. 当前证据，以及新增设计范围的总体复杂度依据
3. 针对阶段 4 中已识别的每项重大风险所采取的控制措施
4. 与阶段 5 中已识别的每项决策相关约束的兼容性
5. 验证级别（L1／L2／L3）和集成点定义

除非已采纳的 ADR 将备选方案记录为决策历史，否则这些方案仍属于待讨论的分析内容。

验证级别定义

各任务完成情况的验证优先级：

• L1：功能运行验证 - 作为终端用户功能运行（例如，可执行搜索）
• L2：测试运行验证 - 新增测试并通过
• L3：构建成功验证 - 代码构建／运行无错误

优先级：按可验证性的重要程度，L1 > L2 > L3

集成点定义

根据所选策略定义集成点：

• 基于绞杀者模式：每项功能在新旧系统之间切换时
• 功能驱动：用户实际能够使用该功能时
• 基础驱动：所有架构层就绪且端到端（E2E）测试通过时
• 混合方案：各阶段定义的单独目标达成时

质量检查

1. 确认 Phase 1 在选择策略前，已识别当前职责、依赖路径和历史约束
2. 确认 Phase 2 产出一份完整的 Selected Design，且每个新增的设计层面都对应当前证据、较低层面方案不足，以及删减后会失败的条件
3. 确认 Phase 4 针对每项有证据支持的重大风险记录了具体控制措施；不适用的类别无需填写
4. 确认 Phase 5 检查了每项有证据支持且可能改变策略选择或验证方式的约束；不适用的类别无需填写
5. 确认 Phase 7 记录了所选策略、其总复杂度依据和早期验证节点；备选方案仅出现在已接受的 ADR 中

元认知执行指南

1. 利用已知模式：当模式的问题和权衡与观察到的代码库状态相符时，使用该模式
2. 有条件地开展外部研究：在检查代码库后，若与时效性能力、兼容性或依赖相关的决策仍未解决，则使用官方的最新资料
3. 运用 5 Whys：追查根本原因，以把握本质
4. 多角度评估：在选择实现方案前，评估当前状态、收敛性、风险和约束