如果有一些点没有注意，会让图的自我表达变差。
- 方框或其他形状表示什么意思？随意使用方框或其他形状可能会引起误解。
- 形状的边线表示什么意思？虚线、点线等多种形状的边线可能会引起误解。
- 线条或箭头表示什么意思？线条或箭头可以被理解为数据流，也可以表示元素间的关系（比如组件 A 依赖组件 B）。
- 线条或箭头表示哪一种类型的交互或关联？交互类型有流程、数据流，关联类型有依赖、继承、实现等。
- 颜色代表什么意思？一般颜色在架构图里的作用不是非常大，如果使用了多种颜色的架构图却没有适当的文档说明很容易引起误解。
- 不应该单独的元素或实体，不管是从结构还是从行为角度来看，每一个元素或实体都应该依赖系统的其他部分，或者与它们之间存在某些联系。
- 费解的缩略语或含糊不清的名词，切忌使用费解缩略语（HQ/MQ）、含义不清的名称（业务流程、通用模块等可以更具体），这样容易引起困惑。
- 表达内容是与受众关注的重要信息，比如是个业务流程图，不应该包含无关紧要的技术实现细节。一些技术实现
- 在同一个架构图里混杂运行时元素和静态元素。例如运行时的状态流转图，不要与静态数据结构图放一起，导致表达不清晰，可以分开两张图表达。
- 试着把所有必要的信息都包含在架构图里，而不是事后加以说明，不然容易丢关键信息。
- 层级冲突或混合抽象，在同一个架构图里添加不同层级的抽象可能会导致冲突的出现，例如，把组件添加到上下文架构图里，或者把类加到部署图里。
- 使用混乱或含糊不清的架构图表达过量的信息或无效的细节，需要谨慎地选择信息的层级和粒度。
实践指南
- 保持架构图的结构一致性和语义一致性，也会让整张图的逻辑非常严谨。方框、形状、边框、线条、颜色等在一张图内，一种情况，在一张图内表达的语义必须是一致的，没有二义性。更好的情况，是整个公司内做好规范，这些定义在同一类图里是一个语义。
- 图上有图示说明，注明每个架构图元素的用意（比如方框、形状、边框、线条、颜色、缩略语，等等）。
- 使用业内标准的架构描述语言，如 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
基本跟应用整体的分层逻辑对应，上面给了两个分层逻辑。
- L0 是业务线的全局架构；
- L1 是中台 / 平台级别；
- L2 是领域级别，用户、会员、互动营销、员工；
- L3 是应用 / 模块级别；
这里的粒度可以根据公司和组织架构情况做一些适当调整，例如公司有时候会进行团队拆分和合并，比如把员工、帐号、权限合成一个大的基础团队，这里你会发现团队不管怎么拆合，员工、帐号这个领域级别是相对稳定的，可以以个相对稳定的级别做基准，再做适度上下分级，让每个级别的图有一个对应的团队负责维护是比较合适的。可以更好得长期更新维护架构图，让其能与真实的系统情况保持一致。