什么是架构图？

如何画好一张架构图，要做好这件事情首先要回答的就是什么是架构图。我们日常工作中经常能看到各种各样的架构图，而且经常会发现大家对架构图的理解各有侧重。深入追究到这个问题，可能一下子还很难有一个具象的定义，如果我们把这个问题进行拆分（如下图）理解起来就会容易一点。

架构图 = 架构 + 图

按照这个等式，我们可以把问题转换：

• 架构是什么？
• 图是什么？

图是什么？这个比较容易回答，图是一种信息的表达方式，所以架构图，即表达“架构”的图，也就是一种架构的表达方式。也即：

架构图 = 架构的表达 = 表达架构的图

按照这种思路我们需要回答：

• 什么是架构？要表达的到底是什么？
• 如何画好一张架构图？

接下来的内容基本上就是按照这两个维度来做分析。

什么是架构？要表达的到底是什么？

Linus 03 年在聊到拆分和集成时有一个很好的描述：

I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.（让我们认识到一种现象，把复杂系统拆分成模块，似乎并没有降低整个系统的复杂度。它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行交互，变得更加复杂。）

我理解这里描述的系统拆分就是架构的过程，基本出发点是为了效率，通过架构的合理拆分（无论是空间还是时间上的拆分），最终目的让效率最大化。那到底什么是架构，其实没有完全统一且明确的定义，如下三个定义可以参考。

在百度百科上的定义：

架构，又名软件架构，是有关软件整体结构与组件的抽象描述，⽤于指导⼤型软件系统各个方面的设计。

在 Wikipedia 上的定义：

Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.

ISO/IEC 42010:20072 中对架构有如下定义：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

这三个定义也是见仁见智，但是我们基本可以得出：架构体现的是整体结构和组件之间的关系。

架构的本质

这里引用三个观点来探讨架构的本质：

• 架构的本质是为了管理复杂性。
• 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
• 架构的本质就是对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。

上述三个观点提到的内容，基本表达了架构的核心目的：管理复杂性，效率最大化。以及架构的两个主要变化来源：一个是以改善软件质量为目的的内在结构性变化；另外一个是以满足客户需求为目的的外在功能性变化。无论是何种变化，在我看来架构都是在不断的判断和取舍，在业务需求和系统实现之间做权衡，从而来应对未来变化的不确定性，如下图可以比较粗浅直观的表达这种理解。

要表达的是什么？

在 EA 架构领域，有两种常见架构方法 RUP 和 TOGAF，这两个框架也是我们常常了解架构分类的两个维度。从个人的角度，我自己觉得 TOGAF 的分类方式更加广泛使用（如下右图）。

结合日常的业务开发，其实我们更多的是关注业务架构和应用架构，所以把上边的表达式进一步的拆解，在回答如何画好一张架构图之前，我们需要关注业务架构和系统架构，讨论清楚如何进行业务架构和系统架构。

架构的过程其实就是建模的过程

我们都知道现实世界到软件世界或者面向对象的世界的过程，是一个不断抽象的过程，这其中的方法就是不断的建立模型。从现实世界到业务模型，从业务模型到概念模型，从概念模型到设计模型，通过不断的抽象去粗取精，形成对现实世界的层层抽象，所以架构的过程其实就是建模的过程。至此，我们有必要了解一下什么是建模。

百度百科定义：

建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

《Thinking in UML》定义：

建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

从上述两个定义上基本可以了解到建模就是抽象，对业务或现实世界的抽象，虽然不足以帮我们理解架构本身，但是可以将我们上述关注的业务架构和系统架构进一步向下 Down 一层，架构的过程是建模的过程，我们转换成两个简单的问题：模是什么？如何建？

模是什么？如何建？

这是两个比较容易陷入理论性的问题，我们跳出来从结果看过程。接下来通过已经产出的一些架构图来反向看这些架构图是如何产出的，同时来回答这两个问题。

业务建模

回到当下业务本身，对我而言也是全新的，在最初接触的时候凭仅有的行业背景去理解，结合了大量的文档阅读最终产出了如下图示的《业务核心流程图》和《业务功能模块图》。这两张图基本上就涵盖了所有的业务内容。左边的业务流程图得到了这个行业 20 多年从业经验专家认可，他认为这就是 20 多年所从事的业务内容。

图片源于网络，为示意图，侵删

回溯整个过程，特别是左侧的业务核心流程图，今天我们看这张流程图很容易构架起一个基本逻辑来，纵向是不同的业务角色和系统，横向是时间的推进，特别容易理解。但我想说最开始的理解和分析是极其耗时和压力极大的过程。这个过程中我所用的方法就是：

• “把书读厚”：大量的信息输入，同时探求可能性。
• “把书读薄”：归类汇总，形成大图。
• 逻辑对照，确保理解和分析的正确性。

1）把书读厚

下图基本涵盖“把书读厚”的过程，汇聚大量的文档信息，尝试用多维度去形成逻辑。这个维度可能是依据历史经验，也可能是依据文档内容，比如在形成业务大图的过程中，我曾按可能的场景逻辑、可能的系统或领域逻辑分别把多个文档中的内容归类，探求可能性。

这个过程会很枯燥，特别是涉及一些业务的术语内容，理解起来就会很困难。我的方式就是把自己当做一名“探索者”，如同我们玩游戏一样，常常问自己“我的游戏地图全部点亮了吗？”未必要照顾到所有细节，但是需要力求覆盖整体内容。仔细想想，似乎也和日常的读书类似，这期间值得注意的是：

• 重点关注一些业务概念被界定的地方、一些与自己逻辑推理有出入的地方。
• 不断的调整自己阅读过程中记录的维度，矫正自己的分析方向。
• 老老实实用文档中的原话来记录和呈现（这点很重要，特别是阅读英文材料，最好原汁原味的记录，有助于提升自己的专业性）。

2）把书读薄

这个时候的重点是建立“大局观”，尝试梳理自己的逻辑主线，常规逻辑上讲都会划分为横纵，或者矩阵式的框架，当然这需要建立在前期的理解和分析上，这里常常隐含一个最最重要的假设：系统一定是给人用的，一定是解决客户问题的，否则毫无存在的意义。所以核心的套路是：谁？用什么样的服务/功能/能力？解决什么样的问题？从而刻画出：参与者角色、系统能力、交互关系，需要常常问自己的是：边界是什么？输入输出是什么？逐步的通过用例来梳理出业务功能，形成角色—>主流程—>分支流程，进而通过不断的归纳演绎形成最终的业务抽象描述“一张图”。

一个小的细节是不能妄图通过这些过程迅速在大脑里完成大图的绘制，还是需要从小的环节做起，把一部分小的业务闭环做成一个个的小组块，不要让它再占用大脑的空间，然后逐步的整体思考和把握，渐进式的形成大图；与此同时，大图的样式美观先完全忽略，走通逻辑再细致调整。之所以强调这个细节，是因为尝试通过“一张图”去描述一个非常大的业务本身就是件很有挑战的事情，如果不这么做容易让自己变得焦虑和急躁，这是一个慢功夫，需要耐心，需要在关键阻塞的地方慢下来，甚至一遍一遍的反复才能最终完成。

3）逻辑对照

这是一个闭环封装的过程，把前期“读厚”过程中的记录，一些逻辑细节、关键流程都要逐一放到大图里去对照验证，确保业务理解的完整性和准确性，确保业务抽象能够覆盖所有已知的业务用例，甚至能够支持可能的业务场景。这个环节也是必不可少的部分。

总结一下业务建模（如下图），通过上述三个主要的过程，我们基本可以产出一些业务架构的大图、框图、流程图、用例图等等，是什么样的图并不重要，重要的是这个图面对的是谁？主要用来做什么？我后边也会讲到画图角度的问题。从我们目前的业务场景上看，业务架构图的核心目的是统一共识、减少沟通成本，无论是项目中的哪个角色大家都能讲一样的话，描述一样的事情。这就是建立对话能力和对话语境，特别是有大量外部客户的时候，一方面体现我们自己专业性很重要，另外一方面这种与客户对话的能力更重要，这也是上文中提到为什么要尽可能用原汁原味的文字去呈现一张图的目的。

系统建模

通过业务建模完成了从现实世界到业务模型的构建，在此基础上，如何通过抽象完成业务模型到设计模型的映射，这是系统建模要解决的问题。从研发实现的角度，这个阶段会产出各种各样的模型图，比如实体模型图、时序图、状态图、各个层次的架构图等等，但是无论何种角度，何种层次，系统建模一定是在业务建模的基础上，完成业务需求到系统模型之间的映射；这其中涉及业务功能到系统能力、业务流程到数据流程的映射；系统建模更强调职责、依赖、约束关系，用于指导研发的落地实现。

抛开具体的时序图、状态图不谈，简单看一下如下几个维度的架构图：

图片源于网络，为示意图，侵删

上述几张图的视角、层次和面向用户各不相同，基本上都能看到整体，但是细节程度不同，侧重表达的信息也完全不同。那么系统建模时应该如何去做呢，这个过程中我常常用的方法是（不尽然如此）：

• “剥洋葱式”的由大到小，由粗到细，覆盖所有已知和未来可能业务场景；善于利用各种模型表述：自然语言、关系模型、时序图、状态图、流程图、各种层次架构图等等进行模型表述，充分表达各种业务场景并不断验证。
• 核心实体抽取：抓住核心概念，核心关系完成核心模型建立。
• 终极武器：所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。

1）“剥洋葱”

在业务建模结果的基础上进行“剥洋葱”。这是一个不断拆解的过程，这个过程中的拆解非常重要的方式是就系统分工。如何分工？哪个模块负责什么？模块的输入和输出是什么？内部提供什么样的服务和能力？这几个问题在后文关于抽象的部分回答。一句话总结“剥洋葱”就是：从业务建模的“大局观”去按职责分工拆解成多个子系统、多个子模块、然后在模块能进行细分，层层剥解。

2）核心实体抽取

关于核心实体的抽取，这里的关键问题是：哪些是实体？如何判断核心实体？如何抽取？抽取后的结果是什么样的？很难用一种方法论的形式去描述，我也没有完全形成我自己一成不变的方法论，但是我觉得如下三种方式可以供大家参考。

• 对象的分析方法

实体（Entity）：客观存在并可相互区别的事物称之为实体。实体可以是具体的人、事、物,也可以是抽象的概念或联系。

从这个概念理解，和我们面向对象万物兼对象的理解是基本一致的。所以实体的抽取也可以借鉴对象分析的方法：独立、可抽象、有层次性、在单个层次上又具备原子性。如下图是《Thinking in UML》中关于对象的分析方法。

• 用例分析的方法

通过从业务用例中，去提取其中的关键词，不同的关键词可能表达了实体、关系、属性等等内容，从而完成模型分析与建立。这里引用六铢老师在《问题空间领域模型基本抽象方法》中的的内容，简述如下：

一句完整的用例描述中，首先找名词，以「主语」和「宾语」为主，这些名词基本可以确定我们的实体；其次找形容词，存在于「定语」和「状语」中，找到形容词基本可以确定对应属性的值；然后通过对用例的补充，细化，对名词进行定义，慢慢的，我们会得到我们的领域模型和对应的属性。最后通过动词&形容词（存在于【谓语】，【状语】，【定语】）来确定他们之间的关联关系。

• 问题分析的方法

这是《聊聊架构》中提的方式，具体讲就是通过寻找问题的主体，然后分析主体的生命周期，进而通过区分生命周期里的关键活动来聚焦主体的关键属性和关键关系。推荐大家阅读前 9 章的内容，总计才 40 页的内容，可能会有所体会。这里举一个书中的例子：

一个笑话：一位女士对老公说：把袋子里的土豆削一半下锅；结果所有土豆都下锅了，而且每个土豆被削了一半。

作者指出，这里其实就没有清晰的设别主体，这个主体不单是土豆，而是隐含的人要吃土豆，包括人和土豆两个实体，这两个实体之间的关系就是要解决的业务场景：怎样吃？如何吃？为什么吃？所以主体识别不清楚，可能会导致整体实现的偏离。当然实际过程中不会犯这么愚蠢的错误，但是也侧面说明核心实体的抽取是非常关键的。

3）终极武器：自己讲给自己

实际的业务开发中，往往一种业务设计实现要满足上层N个业务场景，这其中有共性也有个性化诉求，这个过程中我们很容易被多场景之间的异同搞混乱，要么逻辑不清晰、要么过度设计、要么考虑不周。我观察过很多同学包括我自己，在一定的业务复杂度时容易失去设计的焦点。我的做法与业务建模类似，一定要逻辑对照：在所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。请注意这里是“分别套入”，在当前的设计层次下一个场景验证完再去验证下一个场景，找出阻塞的、模糊的点，重新梳理再优化设计。系统建模的结果指导我们软件设计实现，所以一定要反复梳理打通，这个反复的过程其实也是提升架构能力的过程，累积到一定程度就会自然通透。

回到开始的那个问题：

模是什么？通过上面业务建模和系统建模的描述，简单来讲模就是业务的映射，这个映射的结果是业务模型、概念模型或设计模型，但是所有的出发点都是业务需求：客户是谁？核心诉求是什么？

如何建？上面通过业务建模和系统建模两个维度，从个人实践角度大概讲了常规的套路，建模的本质其实一个抽象的过程，但是上述业务和系统建模抽象的过程其实还有两个问题并没有完全说清楚：

• 业务建模中“把书读薄”归类汇总，建立「大局观」，形成大图，这里按什么维度去归类？如何判断归类是正确的？
• 系统建模中“剥洋葱”怎么拆？按什么拆？上述架构图中的层次、领域如何划分层次？边界在哪里？

说回抽象

Haskell 语言的设计者之一 Paul Hudak 曾说过一句略带夸张的话：编程中最重要的三件事是：抽象，抽象，抽象。

“abstraction, abstraction, abstraction”are the three most important things in programming。

如果要问程序员最重要的能力有哪些，我相信抽象一定是其中最重要的之一。那到底什么是抽象？

百度百科定义：

从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃，这种思维过程，称为抽象。

如果更精炼的概括：抽象就是做减法和做除法。通过舍弃非本质和无关紧要的部分，着眼于问题的本质，去粗取精；通过透过现象看本质，发现不同事物之间的共同之处，异中求同，同类归并，也就是做除法。上文中建模过程是共性抽象，通过不断的抽象达到某个状态为止，我理解这个状态没有确定性的答案，核心就是满足业务场景的需要，其实这背后也有一个边界的问题。

抽象的角度

生活中处处都是抽象，但是我们似乎少了为什么是这样或那样抽象的思考。抽象是有角度之分的。

生活中我们常常说“我的观点是…”，其实这里的“观点”就是一个角度问题，从一定的立场或角度出发，对事物或问题所持的看法。以生活中的常见的实物来说（如下图），我们是否能快速的说出其中的相同点和不同点。

如图中已经标注的，我们从功用的角度对它们定义了椅子、桌子、凳子和柜子这样的区分，但显然很有很多很多角度，比如：物料、文字、高矮等等维度，从不同维度看过去，会有完全不同的相同点和不同点表述，所以，本质是什么？本质是：

• 抽象角度其实也是分类的角度，角度不同，会导致完全不同建模方向和结果。
• 抽象的角度就是建模的方向和目的（“屁股决定脑袋”）。

重新回到我们前边的两个问题，业务建模中我们谈到了归类，按什么去归类，答案呼之欲出，按我们的业务流程去归类、按客户的角色去归类，又回到了那个最初始的问题：客户是谁？核心诉求是什么？

同时，上文中我们提到，模是业务的映射，基于对抽象的理解，我们可以进一步展开：模是在确定抽象角度下的业务映射。

抽象的层次

Wikipedia 关于抽象的定义中有一个关于报纸的例子：

\1. 我的 5 月 18 日的《旧金山纪事报》

\2. 5 月 18 日的《旧金山纪事报》

\3. 《旧金山纪事报》

\4. 一份报纸

\5. 一个出版品

这五句话中，我们可以感受到抽象的层次，抽象层次越高，细节越少，普适性越强。再比如下图中关于网络模型的抽象，关于操作系统内核的抽象，我们可以明显的看到不同层次的抽象，就是过滤不同的信息，最终留下来的信息才是当前抽象层次所需要的信息。从系统设计实现上来说，抽象层次越高，越接近设计，越远离实现，同时抽象的模型越不受细节的羁绊，稳定性越高，普适性越强，可重用性就越高。

那么这里抽象的划分层次的依据是什么？原则又是什么？我的经验是，划分抽象层次的依据主要包含两个：

• 以抽象角度分层（可能一层是多角度的聚合）
• 面对变化分层（用层次隔离变化）

其实这个也不能完全解释如何分层，原则是什么？我觉得这是几个最通用的原则：

• 公用的往下走
• 个性的往上走
• 下层可以独立于上层存在
• 控制下层的变化

考虑抽象层次的好处是不论在哪一个层次上，我们只需要面对有限的复杂度，从而专心考虑这个层次上的抽象是什么，要表达的信息是什么。

抽象的边界

除了角度、层次之外，我们还需要考虑的抽象的边界。如果说层次考虑的是纵向维度的表达，那么边界考虑的是横向维度的表达。如何确定边界，一个总的原则是按照职责进行划分，这里的职责其实也就是分工。一旦职责确定，我们在做建模分析时就不需要把整个业务大局放进来从头到尾去分析一遍，我们只需要考虑当前分工下的上游和下游即可，这样的信息量大大减少，自然的我们面对的领域复杂度也会降低到一定程度。

如果一定要给出边界的定义，我的理解是：边界是在确定抽象角度下，通过寻找核心的业务活动，抽取核心实体，进一步确定实体核心生命周期的结果。可能有一点点绕，关键词是：核心业务活动、核心实体、核心实体生命周期。

以现场娱乐行业为例，如下这张图包含了最高抽象层次下业务的全生命周期，这个抽象层次下的主体是什么，我的理解是票，项目生产的结果是票，分销或电商服务是对票的销售，现场是对票的核验，至此以票为核心实体的生命周期结束。

如果我们往下 Down 一层，从项目生产这一个业务活动去看，整个业务流程是这样：

项目管理->场馆座位分销->票房预测->场次管理->配额管理->绘座->票房规划

从生产这个视角去看，核心的实体不是票，而是场次（确定时间、确定地点、确定内容的一场演出或赛事），所有的关键业务活动都是以场次为维度，生产领域里需要考虑的主要就是场次的核心生命周期。

所以，在不同的抽象角度、不同的抽象层次，根据分工的不同会有不同的核心业务活动、不同的核心实体、边界的确定关键在寻找核心的生命周期。寻找生命周期的过程，就是发现内聚的过程；将所有关于生命周期的业务活动累积，就可以提升领域或模块的内聚性。

抽象的评估

前边我们基本说清楚了抽象的角度、层次和边界，从三个维度确定了抽象的结果。那么如何评估抽象结果的好坏呢？答案是“高内聚，低耦合”，当然还有更多的原则，但是单从实践的角度，我觉得这是最最重要的。

耦合是软件结构中各模块之间相互连接的一种度量

内聚是一个模块内部各成分之间相关联程度的度量

“高内聚，低耦合”从内部、外部两个视角去评估抽象结果的好坏。这其中也有对应的原则和方法论，常规的套路是：

• 每次从一个角度来切分，然后换多个角度来审视

• 通过组合、拆分来精化、优化模型与设计（抽象的结果）

• 关键的审视点：

• 耦合性：减少模块间通信量

• 内聚性：功能单一化

• 变化的隔离性：减少信息依赖，建隔离层、虚拟层

抽象的方法论（套路）

我想，至此，我们说清楚了前面的那两个问题：

• 业务建模中“把书读薄”归类汇总，建立“大局观”，形成大图，这里按什么维度去归类？如何判断归类是正确的？
• 系统建模中“剥洋葱”怎么拆？按什么拆？上述架构图中的层次、领域如何划分层次？边界在哪里？

总结前面说的所有关于抽象的内容，形成抽象的方法论（套路）：

• 抽象有两种方法，一种是自顶向下，另一种是自底向上
• 业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程
• 系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程
• 但不绝对，自上而下和自下而上，往往在过程中是随意切换的

下面这张图来自于《Thinking in UML》，我觉得这个循环的过程可以表达上面这四个点，供大家参考。

如何画好一张架构图？

回到主题，如果上边的问题说清楚了，接下来的事情就相对简单了。对于架构图是什么这个问题，我们可以把之前的等式进行延展：架构图 = 架构的表达 = 架构在不同抽象角度和不同抽象层次的表达，这是一个自然而然的过程。不是先有图再有业务流程、系统设计和领域模型等，而是相反，用图来表达抽象的思考和内容。

那么架构图有什么用？给谁看？回答这个问题需要讲清楚为什么要画架构图，同时也需要考虑一个问题就是：架构图是不是越多越好，越详细越好？

画架构图是为了什么？

A picture is worth a thousand words （一图胜千言），从 Why 层面讲，我觉得就是如下两点：

• 解决沟通障碍：达成共识、减少歧义。
• 提升协作效率：团队内部和团队之间的协作、沟通、愿景和指导。

但是上述两点其实是非常笼统的信息，如果放在 What 层面，我们必须要考虑架构图面对的“客户”，不同的客户有不同的诉求（其实也就是角度和层次），在不同的抽象层次架构图所表达的信息内容可以完全不一样。以目前团队做的事情为例，架构图的目标客户至少有几类：

• 参与项目的各团队各角色（业务、产品、开发、测试、安全、GOC）
• 项目之外的客户（外部客户，外部评审专家）
• 各层次 TL（汇报，跨 BU，跨团队协作沟通）

所以画架构图，我们必须首先明确沟通交流的目的和面向的客户，只有明确了这两个点才能更加有针对性的达成上边所说的那两点目标：解决沟通障碍，提升协作效率。

怎么画？

先说分类

架构图分类，本质上是从不同的视角，不同的抽象角度去看，作出清晰、简化的描述，涵盖特点方面忽略无关方面。

从业务应用开发的维度，一般的抽象层次可以分为：

业务全域—>子域—>模块—>子模块—>包—>类—>方法

这其中：

• 较低层次的抽象：应用内部包图、类图；某个领域：实体图、时序图、状态图、用例图等等。
• 较高层次的抽象：具有一定的复杂性，比如微服务架构，系统间的交互图，领域/子领域架构图，整个系统架构图等等。

当然，还有很多其他的分类方式，比如：RUP 4+1，GOGAF9 等等分类方式。单从实践的角度，我觉得何种分类不是最重要的，最重要的是想清楚面向谁和解决什么诉求，然后思考架构图到底从哪个角度、哪个层次去抽象。我们目前所做的项目，有很时候要去和国外的业务专家、技术专家去沟通，大家也并没有一个明确的标准定义，表述清楚问题，达成共识这是最最关键的，至于架构图的粒度、类别、内容可以逐步的去完善，去粗取精，迭代优化。

再说构图

构图的部分，我们大家都用 UML 画过类图，涉及泛化、聚合、组合、依赖等等关系，分别用不同的虚实线、箭头样式进行表达。所以画架构图需要考虑架构图的组成元素，要保证符合一贯理解，架构图的组成元素可能涉及：

• 方框、各种形状、虚实线、箭头、颜色（不同颜色代表什么意思）和文字内容
• 虚实线表达什么？组件类型，模块类型，层，服务，需要考虑是否已经实现等？不同状态的标识怎么传递？
• 箭头表达什么?数据流或关联关系？
• 交互类型可以是同步或异步的；关联类型可以是指依赖、继承、实现

构图最最重要的是需要考虑内容术语一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题。

如何评判架构图的好坏

架构图的好坏，我理解主要是两个方向，一个是需要跳出图本身去看，业务领域的抽象设计合理性，是否符合“高内聚，低耦合”的要求，这个需要回到前文的业务建模、系统建模和抽象过程去寻找答案。另外一个方向是图本身，以下几个点供参考：

• 内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观
• 图中的信息与相应的抽象级别相关，且满足利益相关者(合作方)的需求
• 一张好的架构图不需要多余的文字解释！受众有没有准确接收到想传递的信息；如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图
• 架构图应该帮助每个人看到大局，了解周围的环境，适当的上下文信息
• 架构图应该避免“只见树木，不见森林”

但是，终归还是那句话，“一张图片胜过千言万语”。不管好坏，不管是否美观，人是视觉动物，用图表达可以极大的提升沟通效率，先画起来吧！

最后也聊聊架构师

这是来自于阿白老师的文章《架构师到底是做什么的？》，越是琢磨，越觉得深以为然。其中提到了好的架构师的画像和不好的画像，如下图，与大家共勉。

从我个人的成长经历看，架构师很重要的一点要学会“权衡”，既要兼顾当下痛点也要符合未来一定时间的发展，既要保留未来的可扩展性也要避免过度设计。选择什么样的时间节点、什么样的业务场景以及什么样的架构迭代策略至关重要，这些决策的关键在于判断和取舍，需要结合深刻的业务思考乃至组织架构去做权衡落地。一点点不算经验的经验：

快速学习

快不是一个速度问题，也是一个判断或者标准问题。面对一个全新业务场景，如何能够识别20%的关键业务路径，关键业务痛点，如何短时间把自己变成业务专家这是一个架构师基本的素质。我的一点经验就是要去「吸金式」的思考，带着问题主动思考，客户是谁？有什么诉求？需要解决什么样的问题？我们能提供什么样的价值？多问为什么？这也需要长时间的刻意训练。

不要屁股决定脑袋

要跨角色、跨层级去看待业务问题，这个点容易陷入说教，说实话我自己做得也未必到位。但是时刻提醒自己的思考是否被局限，在哪一个维度，是 Have-do-be，还是 be-do-Have 等等；同时也不断的在提醒自己永远不要屁股决定脑袋。

提升思考能力和对于技术原理或本质的理解

我觉得这是最底层的能力，业务开发中我觉得最大的两个难点：一是逻辑的复杂性，二是需求的变化性。我们不应该大部分时间花在寻找解决方案上，而应该花更多的时间在选择解决方案上。这就要求我们对业务全局、行业深度、技术视野、技术深度、业务共性、个性特征等等形成自己的认知。权衡取舍，取什么舍什么？该怎么取怎么舍？那个度在哪里？唯有思考，自驱，累积和坚持，勇猛精进，志愿无倦。