{辣迭里写侬个标题}

!!! info

**状态**：{ 建议中 | 评审中 | 已接受 |  已否决 | 已取代 | 已弃用 }

**更新**：{YYYY-MM-DD}

摘要

{迭是侬个 ADR 个“执行摘要”或者“电梯演讲”。用几句简洁个话（一般 2 到 4 句），清爽地讲明迭份 ADR 处理个核心问题、疑问或者机会。简单提示一下所做个决策或者关注个领域。目标是帮读者快速了解迭份 ADR 讲个是啥，并且判断搭自家有勿有关系，勿用看完整份文件。可以当作技术论文个摘要，或者对主要话题个很简短个介绍。}

驱动因素

{迭一节讲明为啥现在要做迭个决策。清爽地讲明促使需要做迭个架构决策个主要动机、需要或者问题。想一想背后个原因搭压力。}

{比方：阿拉辣开发一个新功能／新能力，需要……}
{比方：阿拉需要改进性能、可访问性，清理技术债……}
{比方：用户个反馈表明……}
{比方：现在个办法带来迭眼限制……}

选项

{迭里列出侬辣考虑个各种选项。只讲事实，勿要讲意见，下一节才做分析。包括简洁个描述，还有相关文档或者例子个链接。

包括侬探索过个所有重要备选方案，即使最后呒没选伊拉。目标是辣深入评估之前，让读者对每个备选方案有清爽、勿带偏见个了解。}

{选项 1 个标题}

{描述迭个选项，提供摘要，列出事实，提供链接等等。}

{选项 n 个标题}

...

选项分析

{迭里对选项一节里提出个每个选项做批判性评估。对每个选项，平衡地讲伊个优点、缺点，还有任何其他相关个考虑或者取舍。要具体，只要可能，拿侬个论点联系回驱动因素。

考虑迭眼方面：

成本（开发、运营、许可）
复杂度（实施、维护、学习曲线）
风险（技术、运营、安全）
搭架构原则或者现成标准个一致性
对性能、可扩展性、可用性、可维护性、安全等等个影响

按需要包括多少条优点／缺点／其他陈述。 }

{选项 1 个评估}

优点：{迭个选项个一个具体优势或者好处。}
缺点：{搭迭个选项有关个一个具体缺点、风险或者成本。}
其他：{一个勿严格属于优点或者缺点个相关要点。}

{选项 n 个评估}

...

建议

{迭里清爽地讲明最终决策，并且明确写出选定个选项。详细讲明为啥选迭个选项。应该清爽地讲明选定个选项哪能最好地应对驱动因素，满足关键需求或者解决所述问题。}

后果

{迭一节是可选个。}

{现在决策已经做出，预期个结果搭影响有啥，包括正面个搭负面个？做了迭个决策，接受了啥已知个限制、成本或者风险？迭个决策会哪能影响勿同个利益相关者、其他系统、开发实践、运营程序或者用户体验？}

优点：{预期从迭个决策得到个一个具体正面结果或者好处。}
缺点：{迭个决策带来、已经接受个一个具体缺点、成本或者风险。}
其他：{一个勿严格属于优点或者缺点个后果。}

确认

{迭一节是可选个。}

{概述哪能验证迭个决策个实施，哪能确保持续遵守。迭能证明决策勿光是理论，而是会被积极落实搭监督。

侬会哪能检查决策有勿有被正确实施？（比方代码评审、特定测试、演示、同行评审）。

随辰光推移，哪能维持对迭个决策个遵守？（比方自动检查、定期审计、更新团队指南、培训）。

有勿有特定个指标或者迹象，可以表明决策正辣达到预期个正面结果？（比方性能基准、采用率、特定错误减少、用户反馈评分）。

啥人负责监督迭件事体，要是勿遵守决策会哪能？}