技术决策记录

这是什么

使用ADR（架构决策记录）来记录技术决策的结构化方法。确保决策可追溯、理由充分，并被团队理解。

何时使用

选择技术或框架时
进行架构变更时
选择第三方服务时
更改既定模式时
任何你以后想要参考的决策

核心理念

1. 决策是不可更改的历史

一旦做出，ADR不会被修改，只能被取代。这保留了当时的推理，即使后来的上下文发生了变化。

2. 上下文优于结论

“为什么”比“是什么”更有价值。未来的读者需要理解导致决策的约束、选项和权衡。

3. 倾向于可逆性

倾向于以后可以更改的决策。为不可逆的选择记录反转成本。

4. 显式优于隐式

如果没有写下来，那就没有决定。口头协议不算作架构决策。

5. 团队优于个人

决策应该由受影响的各方审查。令人惊讶的决策会产生阻力。

流程

第一步：定义问题

我们在决定什么？具体点。

“用户数据使用哪个数据库”而不是“数据库的东西”
包括触发因素：是什么促使这个决策？

第二步：列出约束

我们的选择有哪些限制？

技术：性能、可扩展性、现有技术栈
商业：预算、时间线、团队技能
合规：安全、法规、数据居住地

第三步：列举选项

列出2-4个真正的选项。对于每个选项：

简短描述
优点（它做得好的地方）
缺点（它做得不好的地方）
估计成本/工作量

第四步：做出决策

选择一个选项。清晰地陈述。

“我们将使用[X]”
包括谁做出了决策以及何时

第五步：记录后果

这个决策会带来什么？

积极的：我们期望的好处
消极的：我们接受的成本
风险：可能出错的地方
可逆性：以后改变有多难

ADR模板

# ADR-[NUMBER]: [TITLE]

**状态**: [提议中 | 已接受 | 被ADR-X取代]
**日期**: [YYYY-MM-DD]
**决策者**: [姓名]

## 上下文

[问题是什么？是什么促使这个决策？]

## 约束

- [约束1]
- [约束2]
- [约束3]

## 考虑的选项

### 选项1: [名称]
[描述]
- 优点：[...]
- 缺点：[...]

### 选项2: [名称]
[描述]
- 优点：[...]
- 缺点：[...]

### 选项3: [名称]
[描述]
- 优点：[...]
- 缺点：[...]

## 决策

我们将使用**[选项X]**。

[推理：为什么选择这个选项而不是其他？]

## 后果

### 积极的
- [好处1]
- [好处2]

### 消极的
- [成本1]
- [成本2]

### 风险
- [风险1]：[缓解措施]
- [风险2]：[缓解措施]

### 可逆性
[容易 | 中等 | 困难 | 不可逆]
[解释反转将需要什么]

常见错误

1. 无选项决策

在没有探索替代方案的情况下做出决策不是决策——这是默认。

为什么这是错误的：你不能在不知道你选择了什么的情况下证明选择。

相反：总是至少列出2个选项，即使其中一个是“不采取行动”。

2. 自行车棚效应

在可逆决策上花费的时间比不可逆决策多。

为什么这是错误的：在低风险决策上花费的时间是没有用在高风险决策上的时间。

相反：将审议时间与可逆性相匹配。不可逆=更多流程。

3. 隐藏的利益相关者

在没有涉及受影响团队的情况下做出决策。

为什么这是错误的：会造成惊讶、阻力和返工。

相反：在“决策者”中列出受影响的各方，并得到明确的批准。

4. 修改而不是取代

当上下文变化时编辑旧的ADR。

为什么这是错误的：失去了为什么做出决策的历史记录。

相反：创建一个新的ADR来取代旧的，引用原始的。

技术决策

你在处理什么技术决策？

在决定什么？
- 技术选择
- 架构模式
- 第三方服务
- 流程变更
- 其他：___
是什么触发了这个决策？
- 新需求
- 性能问题
- 技术债务
- 团队变更
- 其他：___
这应该是多容易改变的？
- 容易改变（实验）
- 更改需要适度努力
- 重大投资
- 难以逆转（谨慎承诺）

我将根据你的回答帮助你构建ADR。