无情岁月增中减，有味诗书苦后甜。

最重要的一点

并不是如何做架构：）

而是我的架构为谁而作，说的简单点就是，我们的写的架构文档，是开发来读、运维来读、还是项目经理来读，又或是不懂技术的老板来读呢？

我想，不同的读者需要的是不同的架构文档。

为什么呢？

总得来想，我觉得是分工带来的困境。

当每个人都只关注自己的领域的时候，谁来设计全局蓝图呢——告诉大家我们要的系统的是这样的。

我想架构师就是来做这样一件是事情的，他描绘了系统的蓝图——架构。



怎么来理解这张图呢？

我想大家，一定认为这张图最重要的元素是架构吧，毕竟我们讲的就是架构师嘛。然而，相关方才是最核心的，一切都是围绕相关方来执行的。

首先架构不是凭空产生的，它是整个系统的蓝图，而系统也不是没有来由的，它是相关方的利益所在，这个系统也并不是我一个人来落地，需要团队协作，那怎么才能让团队中的每个人都理解我们的意图呢？

架构文档就是来做这样一件事的，而其中不同的视图又为不同领域职能的同事提供了指导。

至于，架构元素与架构元素之间的关系就是组成架构的关键，是狭义的如何做架构的内容，而广义的内容就是完整的这幅图。

现在我们再回到开头，怎么架构就不是这张图最重要的内容呢？

我写到这里，发现这张图说明了三个问题：

1. 为什么要有架构

2. 架构是长什么样的

3. 架构如何落地

很明显，第一个问题是最关键的嘛。但是，为什么的问题，一般也轮不到我们架构师来费神：），由此说来，我们的主要工作还是在解决后两个问题。

使用UML来描述我们的架构

好了，我们现在已经知道我们的架构是为谁做的了。这件事的意义再哪里呢？我觉得课上老师讲到的一句话提醒了我。“我最不想合作的一种人，就是那种只为工作而工作的人。”一开始听确实是模糊，但细细一琢磨，这类同事只为自己负责，他人又如何与他有效合作呢？架构师的架构为谁做，就是对谁负责。因为我们需要将我们的架构意图清晰告诉每一人，他们才好开展自己的工作。事情都讲不清楚，工作的开展又怎么能顺利呢？

那么如何使用表述清楚我们的意图呢？

UML。

在工作中，我们主要使用部署图、类图、组件图、用例图和序列图、活动图、状态图来描述架构。前者属于静态图，后者是动态图。其中的重点不是如何绘制这些图，而是该如何使用这些图来描述我们的架构。

部署图

它的单位是服务器，最直观的告诉同事我们的架构是如何用服务器组织起来的，通常读者是运维工程师。

类图

顾名思义，是对代码层面的类的描述，说明了两件事情：

1. 类是什么样子的

2. 类和类之间的关系是如何的

当然，这一部分是开发工程是重点关注的。

组件图

我的理解是一套controller+service+dao就可以理解为一个小组件，或者一组这样的小组件合成一个大组件，就微服务来说，一个服务也可以理解为组件。读者一般也是开发工程师。

用例图

描述了一个或多个组件有哪些使用方，这些使用方又有哪些操作。从我的理解上看，我一般在产品给出需求后，会绘制这个用例图，然后和产品一起讨论，达成共识后才开展架构或者开发工作。那么用例图的读者可以是产品方了。

序列图

说了上面好几个图，都是静态图。那如何来描述功能或者一个API的流程时序呢？这就是序列图的作用了。就电商下单的逻辑来说，你可以从服务的粒度来描述整个过程——经历过那几个服务，做了哪些事情，服务之间是同步调用，还是异步调用，当然也可以关注一个服务内部的逻辑处理经过——经历过哪些service、做了什么事情。这部分主要还是开发工程师来阅读，当然测试工程师也是它的读者。

状态图

常用来描述类的状态，以及类的状态变更条件。

就像一个订单的状态，有哪些订单状态，这些订单的状态是如何转变的。如果用word来描述的话，密密麻麻的文字，看得就让人头疼，用一张图来表述就很清晰。这一部分的读者，应该有开发、测试和产品。



说到这里，首先我们架构师要对做的系统有个全局的认识，这个认识可以模糊的，也可以是明确的。如果是模糊的，那么就边画图，边梳理自己的认识；如果是明确的那就明白白清清楚楚地画图告诉大家。不知道大家看到这里，会不会有个疑惑，小结了这么多，通篇说的都是软绵绵的东西，都没有说到技术性很强的点。其实刚开始小结的时候，我也是有这样的疑惑的，但是梳理到这里，我豁然开朗。对系统要有个全局的认识，这件事本身就很有技术含量，此时我们熟知的分布式、微服务、各种中间件还有对“三高”要求，都会在这这一层次体现出来。