工件:架构备忘录
此工件描述那些在形成架构过程中所做决策的原理、假设、解释、以及影响。
域:架构
用途

捕获并做出架构决策,以及向开发人员解释这些决策。

关系
完成的槽
角色负责人: 修改者:
任务输入至:


输出自:
描述
主要描述

此工件描述了软件架构

它提供了一个地点维护架构问题清单,以及相关的架构决策、设计、模式、代码文档(或指向)等等——所有这些都在一个适当的层次上,以使已做出和未做出的架构决策更容易被理解。

使用此工件有助于架构师在架构开发中同其他团队成员协作,并帮助团队成员理解架构决策背后的动机,从而使这些决策能够被更坚定的执行。例如,架构师可能对数据如何打包以及如何在系统不同部件之间如何通信进行约束。这看起来可能是种负担,但是在架构备忘录中可以给出理由解释原因,在与遗留系统之间的通信中存在显著的性能瓶颈。其余的系统必须通过特定的数据打包方案来适应这个瓶颈。

此工件同时应该告知团队成员系统是如何被划分或组织的,从而团队能够适应系统的需要。同时,它还为后续那些维护和变更架构的人提供了系统的初始概貌及其技术动机。

简述

作为最低限度,此工件至少应该完成以下三件事:

  • 列出需要遵循的指导方针、决策和约束
  • 给出这些指导方针、决策和约束的理由
  • 描述架构机制以及它们被应用的地点

没有参与这些架构决策的团队成员需要理解架构上下文背后的原因,从而能够处理系统的需要。在适当的时候,考虑添加更多的信息。小项目不应该花费太多的时间编写架构文档,但是所有系统的关键元素必须同当前或未来的团队成员进行沟通。下面是所有有用的内容:

  • 架构的目标和思想
  • 架构假设和依赖
  • 对架构关键性需求的引用
  • 对架构关键设计元素的引用
  • 关键系统接口
  • 打包子系统和组件的说明
  • 分层和关键子系统
  • 关键抽象
  • 描述了系统关键行为的关键场景
图示
定制
不具有的影响

没有此工件,将无法协调独立的设计工作,并且将难以建立和沟通项目的整体架构愿景。

不需要的原因

如果使用了已经存在的参考架构,或有使用了其它方式或工件文档化架构,则不需要此工件。如果设计相对简单并且没有任何关键的架构风险,也可不需要此工件。

说明选项

架构模型集合可以作为架构文档的一部分进行开发。更多信息,参见指南:Modeling the Architecture

更多信息