【CSDN 编者按】本文作者从架构图的目的、怎样的架构图是好的架构图、如何画好架构图，以及各类经典架构图的分类和示例都做了详尽解析，是一篇不可多得的干货文章，建议点赞收藏！

　　架构图 = 架构的表达 = 架构在不同抽象角度和不同抽象层次的表达，这是一个自然而然的过程。

　　架构图是架构师、产品经理、开发工程师、测试工程师等各种角色之间进行沟通的语言和桥梁，让整个团队更能有效地协调工作。设计图不单单是架构师要掌握的，在一个产品的开发过程中，任何一个环节和角色都可以通过掌握不同的设计图来完成沟通。

　　明确架构方向：架构图可以帮助技术团队明确产品和技术的方向和目标，避免在开发过程中迷失方向或者偏离主题。

　　降低沟通成本：将系统逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，使得团队更加直观地了解产品的设计和功能，尽快达成共识、减少歧义；

　　提升协作效率：团队内部和团队之间的协作、沟通、愿景和指导。通过架构图可以更好地给项目成员进行宣讲。开发人员可以更加清晰地了解产品的整体结构和各个模块之间的关系，从而提升开发效率。

　　结构清晰：观点明确、层次分明、内容清晰。用户轻易看出架构图表达的观点/关系/思想/逻辑 。通过架构图，各个团队了解业务、应用整体大局。

　　外表美观：用户看得舒服，有更多的浏览欲/阅读欲，通过不同颜色和布局来体现美观：图例清晰，颜色类型统一，美观。

　　如果项目已经进行了一半，或者项目都已经结束了，但自己却从未画过架构图。 那么从此刻开始，动手开始画吧。 有一句话“种一棵树最好的时间是十年前，其次是现在”。

　　已经从不同的视角，不同的抽象角度去做好架构分类： 业务架构、应用架构、技术架构、代码架构、数据架构等。

　　横向分层构建：按照功能处理顺序划分应用，比如把系统分为 web 前端/中间服务/后台任务，这是面向业务深度的划分。

　　纵向是模块划分和跨层统一相关规范流程： 规范流程一般是放具体的标准、规范等，比如安全管理、质量管理、技术标准规范、开发运维规范等。

　　抽象思维： 架构构图中的层次如何划分？ 边界在哪里？ 应用模块边界如何确定，怎样才能做到高内聚，低耦合。 这些都需要抽象思维。

　　分层： 分层也是我们应对和管理复杂性的基本思维武器，目的是为了解耦。 将业务按照层级区分，每个层级为独立的逻辑模块层，每一层专注解决某个领域的问题。 下层更抽象，上层更具体 。 层级需要有逻辑上的关联，如下层为上层服务或者提供能力支撑。

　　分模块： 是在同一逻辑层中，有哪些独立模块。 一个模块代表一个完整的业务或者同类型的业务聚合。 每个模块之间相互独立，且模块之间也会存在依赖或者关联。

　　分功能： 在同一个模块内，将独立的功能划分出来，该功能可以代表一个业务入口，简单理解就是一个模块体系中的功能，比较具有代表性，用户比较关注的功能抽象出来。

　　在画架构图前，有必要对整个业务体系进行系统性思考，将穷举所有涉及到的应用、功能、系统、模块、能力、平台罗列出来。 然后进行提炼、归纳、分类、总结，然后分类构建代替框架思路，最后按照分层、分模块、分功能的维度将具体的内容填充。

　　架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。 架构图的结构外观应该是一样的，团队不同成员创建的架构图不应该给任何一个利益相关者造成理解上的障碍。 理想情况下，可以在所有项目里使用相同的建模工具。

　　从语义角度来看，所有的架构图与最新的代码变更之间以及架构图与架构图 之间都应该定期保持同步，因为一个架构图的变更可能会影响到其他架构图。 同步可以通过手动进行，也可以通过建模工具自动触发。 通过建模工具自动触发会更好一些，不过这也取决于具体的项目。 最终的目的是要保持架构图和代码之间的一致性，至于使用什么样的方法或工具可以自行决定。 Simon Brown 说，“如果架构图与代码失去了联系，那么就无法用来改进架构”。 他的话其实是在强调保持语义一致性的重要性。

　　虚线和实线、箭头： 一般实线框表示的关系强烈程度高于虚线框，虚线框更重于逻辑上的关联。 线条或箭头可以被理解为数据流（比如从系统 A 到系统 B 的数据流）或元素间的关系（比如组件 A 依赖组件 B）。

　　一个使用了多种颜色的架构图却没有适当的文档说明很容易引起误解（比如为什么有些方框是绿色的，而其他是红色的？ 为什么有些线条是黑色的，而有些是蓝色的？ ）。 颜色在架构图里的作用不是非常大，添加太多的颜色并不会给架构图带来更多有价值的信息。 一个仅仅使用了黑白两色的架构图也应该是不言自明的，除非非常有必要使用特定的颜色来强调图中的某些部分。 在任何情况下都要保持颜色的简单性，如果一定要用多种颜色，不要忘了添加说明。

　　业 务架构是从业务、产品视角，描述整个平台、或某个产品的实现。 包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

　　对产品功能模块的抽象划分，产品架构主要用于讲明白这个产品做什么的、需要有什么功能。 对需求全盘理解之后，进行高度的抽象分类，然后对各个分类进行对应的产品设计，完成抽象的逻辑梳理和数据梳理，逻辑和数据最终组成一个有机体，成为产品架构。

　　业务闭环：用户使用产品的闭环流程基于用户的某个需求或问题，梳理用户使用的业务流程，梳理参与此模块的用户、角色、场景，将核心流程完整的表述出来，形成闭环。

　　基于核心业务流程，根据用户的使用场景列出功能模块。关键是想清楚每个功能模块解决什么核心问题。

　　基于以上梳理出来的功能模块，将类似的、相关联的功能以模块化的形式形成一张简单的矩阵图，将功能模块进行聚合分类。通常按照交互层（入口）、业务层（具体业务环节）、基础服务层（登录、设置等）、数据层（底层服务或数据）进行归纳整理。

　　业务流程图又称为泳道图，就是描述哪些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：

　　泳道图一般是从战略上分析整个业务流程，让你对公司所做的业务有个大概的了解，而任务流程图就是在你的产品操作上，用户通过什么样的操作来完成它的目标，比如你去银行 ATM 机器上取。