设计意图的传达是架构可视化关注的重要维度，在技术方案评审过程中不可避免的会出现各种各样的架构图或设计图，这些图形化表述在设计意图传达效果层面表现不一，本文从图形化的视角为软件架构图的评审关注点提供了参考。

注：关于架构及架构可视化参考文章《探寻软件架构的本质，到底什么是架构？》《软件架构可视化及C4模型：架构设计不仅仅是UML》

1 原则

•明确的主题：架构图要表达的意图明确，比如是容器图、组件图还是部署图

•一致的抽象层级：保持一致的抽象层级，不应超过2个以上的层次变化

•粒度合适的范围：不应试图在一张图表达“所有的东西”，每张架构图聚焦于自身职责边界的范围

•清晰的图例说明：对架构图颜色、形状等有明确的图例，以方便阅读导航

•图形颜色不宜太多：过多颜色增加认知成本，建议不超过 4 种

•图形元素不宜太多：过多图形元素增加认知成本

•明确的连线关系描述

2 评审检查单

如同上线检查单和开发检查单，针对于软件架构图的评审制定一套检查单同样具有价值。不论架构设计者，还是参与设计评审的开发人员，对于形式各异的 “架构图” 是提供通用的参考关注点，以便干系人更多、更深入、更高效、更有针对性的获取架构图的更多信息。

架构图是否具有标题?

是否能够理解架构图的类型是什么？

是否能够理解架构图的范围是什么？

架构图是否有图例？

架构图中每一个元素是否有名字？

是否能够理解架构图中每个元素的类型？ (比如，抽象级别，软件系统？容器？组件？等等)

是否能够理解架构图中的每个元素是做什么的？简要描述信息？

是否能够理解与该元素相关的技术选型（适合标明技术选型的元素）

是否能够理解架构图中使用的所有缩写/简称的含义?

是否能够理解架构图中元素使用的所有颜色的含义

是否能够理解架构图中元素使用的所有形状的含义

是否能够理解架构图中元素使用的所有图标的含义?

是否能够理解架构图中元素使用的所有边框样式的含义? (比如，实线 vs 虚线)

是否能够理解架构图中使用的所有元素大小的含义? (比如，小框 vs 大框）

架构图中的每条线是否有描述关系含义的信息?

是否能够理解架构图中的每个关联关系**（适合标明技术选型的场景）的技术选型**是什么？ (比如，进程间的交互的协议)

是否能够理解架构图中的关联关系的简称或缩写？

是否能够理解架构图中的连线颜色的含义？

是否能够理解架构图中的连线箭头的含义?

是否能够理解架构图中的连线样式的含义? (比如，实线 vs 虚线)

本文描述了软件架构图的一些评审关注点，其实不只是评审的视角，对于任何一个图形化的软件系统架构或设计表诉，如何能够快速的了解其要表达的意图至关重要，对于设计者而言如何快速传递架构设计信息并于干系人达成一致也至关重要。