Architecture 用于记录体系结构备选方案和决策的模板

我们正在制定一个流程，所有架构更改都必须记录在案

---

是否有用于记录备选方案和决策的标准模板？

这取决于您是否使用特定的体系结构框架-其中大多数都带有某种模板。如果你不使用任何，我建议-它是非常轻的。即使您觉得这个框架不可用，您仍然可以从它提供的模板中获益

取决于您希望的详细程度/正式程度。就决策注册而言，我们通常会在每个区域/决策中使用一个文档，尽管最近我们一直在尝试OneNote

至少您要记录（每个选项）：

• 选项说明
• 利弊
• 风险和问题
• 假设和限制
• 注意事项

一份简洁的要点清单（等等）通常就足够了——它不需要是一份大文件

对于更深入/正式/复杂的场景，您可能希望进一步了解，这是我们在此类情况下使用的格式：

摘要

• 问题定义
• 解决方案上下文
• 假设
• 约束条件

评估标准

（这很重要，因为它列出了用于对可用选项进行评分的标准，包括权重等）

建议摘要

• 总结
• 高级比较表（这有助于为不想阅读长文档的人提供“一目了然”的比较；同时，进行并排比较也是一个好主意）

[选项1…N]

• 选项说明
• 利弊
• 风险和问题
• 假设和限制
• 注意事项

---

推荐

我很乐意使用思维导图并在必要时提供详细的文档。

在我的公司，我们发现使用以下格式对我们很有效：

• 背景（我们看到的推动这一决定或改变的问题是什么）
• 决策（我们实际正在做的改变是什么）
• 后果（由于这一变化，哪些事情变得更容易或更困难）

这与我们构建测试的方式类似：

给定一个场景，当我做X时，我希望Y是结果

所以我认为这让我们写作和阅读更自然。YMMV

迈克尔·尼加德（Michael Nygard）做类似事情的博文：

使用了这个

• 头衔
• • 日期
• 地位
• 上下文
• 决断
• 后果

---

我们收集有关建筑决策记录的信息

MADR-降价体系结构决策记录 为架构决策建立一个简单的降价格式

模板内容如下：

# [short title of solved problem and solution]

User Story: [ticket/issue-number] <!-- optional -->

[context and problem statement]
[decision drivers | forces | facing] <!-- optional -->

## Considered Options

* [option 1]
* [option 2]
* [option 3]
* ... <!-- numbers of options can vary -->

## Decision Outcome

Chosen option: [option 1], because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | ... | comes out best (see below)].

Positive Consequences: <!-- optional -->
  - [e.g., improvement of quality attribute satisfaction, follow-up decisions required, ...]
  - ...

Negative consequences: <!-- optional -->
  - [e.g., compromising quality attribute, follow-up decisions required, ...]
  - ...

## Pros and Cons of the Options <!-- optional -->

### [option 1]

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* ... <!-- numbers of pros and cons can vary -->

### [option 2]

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* ... <!-- numbers of pros and cons can vary -->

### [option 3]

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* ... <!-- numbers of pros and cons can vary -->

#[已解决问题和解决方案的简称]
用户故事：[票据/发行号]
[背景和问题陈述]
[决策驱动因素|力量|面对]
##考虑过的选择
*[备选案文1]
*[备选案文2]
*[备选案文3]
* ... 
##决策结果
选择选项：[选项1]，因为[理由。例如，唯一选项，符合k.o.标准决策驱动程序|解决力|…|效果最好（见下文）]。
积极后果：
-[例如，质量属性满意度的提高，所需的后续决策，…]
- ...
负面后果：
-[例如，损害质量属性，需要后续决策，…]
- ...
##选择的利弊
###[备选案文1]
*很好，因为[论点a]
*很好，因为[论点b]
*不好，因为[论点c]
* ... 
###[备选案文2]
*很好，因为[论点a]
*很好，因为[论点b]
*不好，因为[论点c]
* ... 
###[备选案文3]
*很好，因为[论点a]
*很好，因为[论点b]
*不好，因为[论点c]
* ... 

该模板可在以下网址获得：

可持续建筑决策 这篇博文建议如下：

在

的背景下，面对

我们决定让

实现

，接受

在某些项目中，我们使用以下扩展：

在

的上下文中， 面向

我们决定使用

而忽略了

， 要实现

， 接受

，

---

因为

有一个工具，它在源代码存储库中提供了对这些体系结构决策的管理。我们在上开始了讨论。基于降价的模板由@joelparkerhenderson（）收集