架构图

什么是架构图？

平常工做中常常能看到各类各样的架构图，每个人对架构图的理解各有侧重。深刻追究到这个问题，可能很难有一个具象的定义，若是把这个问题进行拆分，理解起来就会容易一点。

1	`架构图 = 架构 + 图`

按照这个等式，咱们能够把问题转换：

架构是什么？
图是什么？

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

按照这种思路咱们须要回答：

什么是架构？要表达的究竟是什么？
如何画好一张架构图？

1	`架构图 = 架构 + 图 = 架构的表达 = 表达架构的图`

什么是架构？要表达的究竟是什么？

在百度百科上的定义：架构，又名软件架构，是有关软件总体结构与组件的抽象描述，⽤于指导⼤型软件系统各个方面的设计。
在 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.

这三个定义也是见仁见智，咱们基本能够得出：架构体现的是总体结构和组件之间的关系。

1. 架构的本质

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

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

上述三个观点提到的内容，基本表达了架构的核心目的：管理复杂性，效率最大化。以及架构的两个主要变化来源：一个是以改善软件质量为目的的内在结构性变化；另一个是以知足客户需求为目的的外在功能性变化。

不管是何种变化，在我看来架构都是在不断的判断和取舍，在业务需求和系统实现之间作权衡，从而来应对将来变化的不肯定性，以下图能够比较粗浅直观的表达这种理解。

2. 要表达的是什么？

在 EA 架构(企业架构)领域，有两种常见架构方法 RUP 和 TOGAF，这两个框架也是咱们经常了解架构分类的两个维度。从我的的角度，我本身以为 TOGAF 的分类方式更加普遍使用（以下右图）。

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

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

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

百度百科定义：

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

《Thinking in UML》定义：

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

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

4. 模是什么？如何建？

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

1）业务建模

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

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

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

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

把书读厚：

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

这个过程会很枯燥，特别是涉及一些业务的术语内容，理解起来就会很困难。个人方式就是把本身当作一名“探索者”，如同咱们玩游戏同样，经常问本身“个人游戏地图所有点亮了吗？”未必要照顾到全部细节，可是须要力求覆盖总体内容。仔细想一想，彷佛也和平常的读书相似，这期间值得注意的是：

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

把书读薄：

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

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

逻辑对照：

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

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

2）系统建模

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

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

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

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

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

“剥洋葱”：

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

核心实体抽取：

关于核心实体的抽取，这里的关键问题是：哪些是实体？如何判断核心实体？如何抽取？抽取后的结果是什么样的？很难用一种方法论的形式去描述，我也没有彻底造成我本身一成不变的方法论，可是我以为以下三种方式能够供你们参考。

对象的分析方法

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

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

用例分析的方法

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

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

问题分析的方法

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

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

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

终极武器 - 本身讲给本身：

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

回到开始的那个问题：

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

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

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

说回抽象

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

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

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

百度百科定义：

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

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

1. 抽象的角度

生活中到处都是抽象，可是咱们彷佛少了为何是这样或那样抽象的思考。抽象是有角度之分的。

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

如图中已经标注的，咱们从功用的角度对它们定义了椅子、桌子、凳子和柜子这样的区分，但显然颇有不少不少角度，好比：物料、文字、高矮等等维度，从不一样维度看过去，会有彻底不一样的相同点和不一样点表述，因此，本质是什么？本质是：

抽象角度其实也是分类的角度，角度不一样，会致使彻底不一样建模方向和结果；
抽象的角度就是建模的方向和目的（“屁股决定脑壳”）。

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

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

2. 抽象的层次

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

个人 5 月 18 日的《旧金山纪事报》

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

《旧金山纪事报》

一份报纸

一个出版品

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

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

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

其实这个也不能彻底解释如何分层，原则是什么？我以为这是几个最通用的原则：

公用的往下走
个性的往上走
下层能够独立于上层存在
控制下层的变化

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

3. 抽象的边界

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

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

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

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

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

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

因此，在不一样的抽象角度、不一样的抽象层次，根据分工的不一样会有不一样的核心业务活动、不一样的核心实体、边界的肯定关键在寻找核心的生命周期。寻找生命周期的过程，就是发现内聚的过程；将全部关于生命周期的业务活动累积，就能够提高领域或模块的内聚性。

4. 抽象的评估

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

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

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

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

每次从一个角度来切分，而后换多个角度来审视
经过组合、拆分来精化、优化模型与设计（抽象的结果）
关键的审视点：耦合性：减小模块间通讯量；内聚性：功能单一化；变化的隔离性：减小信息依赖，建隔离层、虚拟层。

5. 抽象的方法论（套路）

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

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

总结前面说的全部关于抽象的内容，造成抽象的方法论（套路）：

抽象有两种方法，一种是自顶向下，另外一种是自底向上；
业务建模，是从小到大，从局部到总体，自底向上的概括、演绎的抽象过程；
系统建模，是从大到小，从总体到局部，自顶向下的拆解、切分的抽象过程；
但不绝对，自上而下和自下而上，每每在过程当中是随意切换的。

下面这张图来自于《Thinking in UML》，我以为这个循环的过程能够表达上面这四个点，供你们参考。

如何画好一张架构图？

回到主题，若是上边的问题说清楚了，接下来的事情就相对简单了。对于架构图是什么这个问题，咱们能够把以前的等式进行延展：

架构图 = 架构的表达 = 架构在不一样抽象角度和不一样抽象层次的表达，这是一个天然而然的过程。 不是先有图再有业务流程、系统设计和领域模型等，而是相反，用图来表达抽象的思考和内容。

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

1. 画架构图是为了什么？

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

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

可是上述两点实际上是很是笼统的信息，若是放在 What 层面，咱们必需要考虑架构图面对的“客户”，不一样的客户有不一样的诉求（其实也就是角度和层次），在不一样的抽象层次架构图所表达的信息内容能够彻底不同。以目前团队作的事情为例，架构图的目标客户至少有几类：

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

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

2. 怎么画？

1）先说分类

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

从业务应用开发的维度，通常的抽象层次能够分为：

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

这其中：

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

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

2）再说构图

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

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

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

3. 如何评判架构图的好坏

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

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

可是，终归仍是那句话，“一张图片赛过千言万语”。无论好坏，无论是否美观，人是视觉动物，用图表达能够极大的提高沟通效率，先画起来吧！

最后也聊聊架构师

这是来自于阿白老师的文章《架构师究竟是作什么的？》，越是琢磨，越以为深觉得然。其中提到了好的架构师的画像和很差的画像，以下图，与你们共勉。

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

1. 快速学习

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

2. 不要屁股决定脑壳

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

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

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