这里用于记录 Cosmos Hub 中新功能与模块提案的所有高层架构决策。 架构决策（AD）是指为满足在架构层面具有重要意义的功能性或非功能性需求而作出的软件设计选择。 架构上重要的需求（ASR）是指对软件系统的架构和质量具有可衡量影响的需求。 架构决策记录（ADR）用于记录单个 AD，这种做法常见于个人笔记或会议纪要；在一个项目中创建并维护的 ADR 集合构成其决策日志。以上内容都属于架构知识管理（AKM）的范畴。 你可以在这里进一步了解 ADR 的概念。

​
原理说明

ADR 旨在作为提出新功能设计和新流程的主要机制，用于收集社区对某个问题的意见，并记录设计决策。 一个 ADR 应当提供：
  • 相关目标和当前状态的背景
  • 为实现目标而提出的变更
  • 优缺点摘要
  • 被舍弃的解决方案空间以及舍弃原因
  • 参考资料
  • 变更日志
请注意 ADR 与规范（spec）之间的区别。ADR 提供的是架构变更或某个全新架构的背景、直觉、推理和论证依据。规范则是对当前状态的高度压缩、更加精炼的总结。 如果已记录的决策后来证明存在不足，应召开讨论，在这里记录新的决策，然后修改代码以保持一致。

​
创建新的 ADR

请阅读流程。

​
使用 RFC 2119 关键词

在编写 ADR 时，请遵循编写 RFC 的同类最佳实践。 编写 RFC 时，会使用关键词来表示规范中的要求。 这些词通常会大写书写：“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL”。 应按照 RFC 2119 中的说明来理解这些词。

​
ADR 目录

​
已接受

  • 无

​
提议中

  • 无

​
草案

  • 无

​
已拒绝

​
已弃用

This is a location to record all high-level architecture decisions for new feature and module proposals in the Cosmos Hub. An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM). You can read more about the ADR concept here.

​
Rationale

ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. An ADR should provide:
  • Context on the relevant goals and the current state
  • Proposed changes to achieve the goals
  • Summary of pros and cons
  • Discarded solution spaces and why they were discarded
  • References
  • Changelog
Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. The spec is much more compressed and streamlined summary of everything as it stands today. If recorded decisions turn out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.

​
Creating new ADR

Read about the PROCESS.

​
Use RFC 2119 Keywords

When writing ADRs, follow the same best practices for writing RFCs. When writing RFCs, key words are used to signify the requirements in the specification. These words are often capitalized: “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL. They are to be interpreted as described in RFC 2119.

​
ADR Table of Contents

​
Accepted

  • n/a

​
Proposed

  • n/a

​
Draft

  • n/a

​
Rejected

​
Deprecated