你知道如何画好一幅架构图么？
用一分钟时间，你能在脑海里构造一幅你最熟悉的系统的架构图么？先别往下看，自己先想象下。
混乱的架构图
不知道你想象中的软件架构图是怎样的，但我猜想大家画的应该跟百度或者谷歌搜索“架构图”出现的结果一样：五花八门、形状各异。
导致这个现象的原因，个人认为有以下几点：
- 软件架构的定义在大多数人心里不够清晰
- 软件架构是多维的，难以用简单某个维度描绘全景
- 不同角色对于一个系统的关注点不一样，因此其期望的软件架构图就会不一样
- 对于软件架构图这个领域缺少一个全软件行业通用的“领域通用语言”，导致不同公司/人对 同一个名词的理解各有差异
本文将试图从以上几个原因出发，理清架构图与架构的关系，让大家能画出与场景、角色相符的架构图。
何谓软件架构
要画架构图，那么我们首先需要清楚架构是什么东西。
维基百科中，其说明软件架构描绘的是：
- 构建构件及软件系统的高层规则
- 软件系统高层构件相互协作关系
软件系统中的“架构”一词引申来源于建筑学中的“架构”，架构是一个软件系统的蓝图，其将会为后续的详细设计团队指明设计方向,也会为不同的系统相关方提供一个快速了解系统设计的途径。
因此架构也是一个系统的根基、骨架，其在整个软件系统生命周期中是详细设计的基础，若要改动则会伤筋动骨。
因此在架构设计时对各种构件的选型应综合考虑各方面的诉求，适当选择tradeoff,避免架构成为整个系统的瓶颈。
软件架构的维度
我们对一个软件系统有很多维度的要求，例如：
- 功能性需求
- 系统容错性(fault-tolerance)
- 向后兼容性(backward compatibility)
- 可扩展性(extensibility)
- 可靠性(reliability)
- 可维护性(maintainability)
- 可用性(availability)
- 安全性(security)
- 易用性(usability)
- ......
不同的角色，对一个软件系统架构所关注的角度也不同，例如：
- 用户关注的是其功能实现、易用性及可靠性
- DDD的模型设计者关注的是各个领域模型之间的关系
- 开发者关注的是使用的开发技术栈、开发是否简单
- 运维关注的是安全性、可用性、系统容错性、物理部署等
- 系统所有者可能关心的是系统的可扩展性、可维护性
我们从上面可以看到，开发设计一个软件系统需要综合多个维度的考量，然而我们所看见的图仅是一个二维的表示，正所谓横看成岭侧成峰，是没有办法把如此多维的信息一次过展现出来的。
因此需要完整地描述一个系统的架构必然需要从不同的维度出发，正交分解出某个维度的关注点，并将其在二维的图中将其展示出来。
当各个维度都描述完成，在读者人脑中，对这些二维数据进行组装后，这个系统的立体形态就会被完整地呈现出来。当然不同人关注点也不一样，可能也没必要每个人都熟悉一个系统的所有视图。
回到标题所描述“画一个你最熟悉系统的架构图”时，我们可以知道，这个问题可能并不太严谨，因为架构是多维的，一幅架构图只能从某一个维度去描绘架构。当然，这问题也有正确解，就是你从多个维度分别画出多个架构图。
软件架构的视图
正如上所说，软件架构是多维的，受限于人类的思考能力及展示工具，我们只能选择从某个视图（角度/维度）去看一个系统，因为看一个系统的维度很多，因此不同公司在内部诞生了很多不同的名词：
- 技术架构
- 逻辑架构
- 物理架构
- 系统架构
- 应用架构
- 开发架构
- 运行架构
- 数据架构
- ......
不知道大家看晕了没有，反正我是看晕了。以上的各种架构的名词在不同的公司会有不同的含义，例如逻辑架构一词，有的公司指代的是从业务逻辑维度看的架构（DDD的模型等），有的公司可能则指代一些中间件之间的主要协作与交互。
实际上一个名词在不同公司有不同含义是很正常的事情，这取决于个人背景、或者更具体的——各个公司领导有没有对某个名词原有的含义产生误解（或者说名词自身就含有歧义）。
因此大家与人交流时，不必纠结于名词自身，更不必因名词定义而对某样事情否定，我们在交流过程中应该寻找名词背后的逻辑。
4+1视图
上面的各种名词混乱当然不是一个好的现象，我们当然最好能构建一个“统一通用语言”，而4+1架构视图是一个相对流行的架构视图划分方法。
4+1：
- 逻辑视图
- 开发视图
- 物理视图
- 运行视图
- 业务场景视图
逻辑视图
逻辑视图关注的是提供给最终用户的功能，因此其描述的是各个功能相关构件之间的协作关系，主要面向用户、业务人员、开发组织。
其主要从系统的功能元素、以及它们的接口、职责、交互维度入手。主要元素包括系统、子系统、功能模块、子功能模块、接口等。
如UML中的类图、DDD中的模型，微服务中的各个服务间协作关系 等都属于逻辑视图的范畴。
开发视图
开发视图从程序员角度去描绘架构，主要关注各类软件包之间的协作关系，其不仅仅包含自己写的包，还包括应用程序依赖的SDK、第三方类库、中间件等。
在DDD/MDD的理念中，在自行管理表征业务逻辑的包/代码将会和逻辑视图的模型一一对应。
软件分层图、开发技术栈图、应用与中间件协作视图 等都属于开发视图的一部分。
物理视图
物理视图是从系统管理员的角度描绘系统的。其主要关注系统软件组件在硬件层次的部署以及系统硬件之间相互协作关系。
物理视图会包含具体的物理硬件及其部署的应用，如F5及其负载均衡、应用服务器及在上面运行的应用、各类中间件服务器及其上面运行的中间件还有网络及IP等等元素
一个合理的物理架构设计，能支持经过合理设计的软件系统实现 高可用、横向扩展等特性
运行视图
运行视图侧重于描述系统运行态，关注解释系统在执行中的动作和组件如何沟通。
对于本视图，个人了解不深，也无法举例说明。往各位大佬指点。
业务场景视图
用部分关键业务场景来描述软件系统自身。这些业务场景案例可以用来走查架构设计中各个对象的协作关系，校验整体架构设计的合理性，并作为验证架构原型可用性的测试案例。
其他视图
除了4+1视图外还有一些额外的视图：
- 数据视图（数据持久化、副本策略等）
- 安全视图
如何画好一幅架构图
再次回到标题，到现在，我们知道，要画好一幅架构图，首先需要明确的是我们要从多维的架构里选择哪一维作为展示的重点。或者说，我们要明确画的这幅图是给谁看的，其对这幅图所关注点是什么。
这样我们才可以有的放矢，在其所关注的维度（逻辑、物理、运行、开发、数据等等）里，选择其关注的粒度（系统、服务、实例、接口等等）进行架构的描绘，才能获得特定阅读者赞同，因而才能成为一幅好的架构图。
而对于一幅架构图的关注点不明确/需求不明确时，我们能给出的图必然是模棱两可，触达不到痛点的。希望我们能记住这一点，以此律己律人。
最后
本文是基于目前个人理解及多篇文章的参考而成，若本文对你有帮助，麻烦右下角点赞～，若文章有谬误，望不吝批评斧正！
作者简介：多年金融码农，现为某信用卡中心架构师，EasyTransaction作者，欢迎关注作者公众号：
ref:
