日常我们在设计方案或者讨论时，经常会看到各种图，这里先统称架构图。另外在一些规划、汇报、总结、分享里面也经常出现各式各样的架构图，有的图还好一看就明白，有的图需要画图人讲、补充说明才能勉强说明白。从个人经验来看，不同项目之间以及同一个团队的不同开发人员之间创建架构图的方式也是很不一样的。也看到过很多问题，比如一致性问题、碎片化问题、信息粒度大小的问题，所以想简单理一理，怎么画好架构图让人更好理解。
介绍
“一张图片胜过千言万语”，架构图是架构工作的关键部分，架构图能帮助与许多不同类型的相关者沟通想法，以满足的不同沟通需求。也做产品的唯一表达，让团队对产品、系统的实际情况理解保持一致。而如上所述，设计软件架构图并非一件轻而易举的事情，即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于为不同的利益相关者澄清事实，并达成共识。
另外，如果你想整理整个公司架构，你会发现图很多，但想整体表达系统架却有一些困难。单个图不能向每个类型的相关者传达其含义，如何有效的有结构的组织这些架构图，也变得非常重要，能相互衔接形成闭环。
基本逻辑
1. 基于目的和目标受众，构建架构图的表达形式，能让你的目标目标受众共鸣，戳到关键点。
2. 架构图是架构的表达，是模型设计的表达，如业务模型和系统模型等。
3. 模型是重要的信息的表达，比如结构、元素、关系、属性、原则，忽略重要信息导致模型模糊，放了不重要信息增加认知负荷。
4. 架构图必须是自描述的，并且要具备一致性和足够的准确性。
如果用“神”和“形”来对比的话，前面3点是图的“神”，第4点是图的“形”，“神”得靠个人的底层架构能力，下面主要说说“形”上我们要注意的一些东西。
常见不足
如果有一些点没有注意，会让图的自我表达变差。
1. 方框或其他形状表示什么意思？随意使用方框或其他形状可能会引起误解。
2. 形状的边线表示什么意思？虚线、点线等多种形状的边线可能会引起误解。
3. 线条或箭头表示什么意思？线条或箭头可以被理解为数据流，也可以表示元素间的关系（比如组件 A 依赖组件 B）。
4. 线条或箭头表示哪一种类型的交互或关联？交互类型有流程、数据流，关联类型有依赖、继承、实现等。
5. 颜色代表什么意思？一般颜色在架构图里的作用不是非常大，如果使用了多种颜色的架构图却没有适当的文档说明很容易引起误解。
6. 不应该单独的元素或实体，不管是从结构还是从行为角度来看，每一个元素或实体都应该依赖系统的其他部分，或者与它们之间存在某些联系。
7. 费解的缩略语或含糊不清的名词，切忌使用费解缩略语（HQ/MQ）、含义不清的名称（业务流程、通用模块等可以更具体），这样容易引起困惑。
8. 表达内容是与受众关注的重要信息，比如是个业务流程图，不应该包含无关紧要的技术实现细节。一些技术实现
9. 在同一个架构图里混杂运行时元素和静态元素。例如运行时的状态流转图，不要与静态数据结构图放一起，导致表达不清晰，可以分开两张图表达。
10. 试着把所有必要的信息都包含在架构图里，而不是事后加以说明，不然容易丢关键信息。
11. 层级冲突或混合抽象，在同一个架构图里添加不同层级的抽象可能会导致冲突的出现，例如，把组件添加到上下文架构图里，或者把类加到部署图里。
12. 使用混乱或含糊不清的架构图表达过量的信息或无效的细节，需要谨慎地选择信息的层级和粒度。
实践指南
1. 保持架构图的结构一致性和语义一致性，也会让整张图的逻辑非常严谨。方框、形状、边框、线条、颜色等在一张图内，一种情况，在一张图内表达的语义必须是一致的，没有二义性。更好的情况，是整个公司内做好规范，这些定义在同一类图里是一个语义。
2. 图上有图示说明，注明每个架构图元素的用意（比如方框、形状、边框、线条、颜色、缩略语，等等）。
3. 使用业内标准的架构描述语言，如UML，按其标准定义来制作。
例如：
架构图分级L0～L4
核心是要有统一的分级的框架结构，下面给大家看一些实践的分级案例。
（PS：这里可以说很多，时间有点不够简单列一列）
SalesForces的分级框架
SalesForce把图分为两类：偏文档说明和实现（Documentation & Implementation）, 偏市场、销售策略（Marketing, Strategy & Sales）
1.Marketing, Strategy & Sales
Purpose: Help viewers understand concepts or a vision for a solution.
Audience: Business & Executive Stakeholders, Technical Influencers
2.Documentation & Implementation
Purpose: Help viewers understand an implementation or product-related technical detail.
Audience: Delivery Teams, Technical Stakeholders
四级框架Level1~Level4
明确图表的意图和受众，决定什么样的细节最能支持你的目的，使用“分级”的概念来帮助将不同的细节划分为易于选择的类别。选择合适的级别可以看清楚一些的细节，使是高度复杂的图表也可以很容易地让查看。当您从Level 1级看到Level 4级时，可以放大更大的细节级别，更细的粒度。
更详细的可以看原文链接：https://architect.salesforce.com/diagrams/framework/overview
一些现成的Demo链接：https://architect.salesforce.com/diagrams#template-gallery
某大厂的分级框架
按架构分层来定义
1
2
基本跟应用整体的分层逻辑对应，上面给了两个分层逻辑。
1. L0是业务线的全局架构；
2. L1是中台/平台级别；
3. L2是领域级别，用户、会员、互动营销、员工；
4. L3是应用/模块级别；
这里的粒度可以根据公司和组织架构情况做一些适当调整，例如公司有时候会进行团队拆分和合并，比如把员工、帐号、权限合成一个大的基础团队，这里你会发现团队不管怎么拆合，员工、帐号这个领域级别是相对稳定的，可以以个相对稳定的级别做基准，再做适度上下分级，让每个级别的图有一个对应的团队负责维护是比较合适的。可以更好得长期更新维护架构图，让其能与真实的系统情况保持一致。
·············· END ··············
往期文章精选：
1.业务分析
