目录
笔者最近有幸参加架构师培训的课程，在纪老师的指导下， 第一阶段已经圆满结束，第一阶段内容重点是：
-
在培养大家《面向对象的编程思想》以及《软件设计原则》的落地实现方案。
-
借助《UML》和《三类架构图》培养大家计算思维以及架构抽象能力。
笔者在此过程中，收获满满，尤其是对UML中的六种关系以及业务架构图的理解和学习，特此与大家分享，希望大家可以共同进步，一起成长。
业务架构图的理解——5W2H分析法
-
一、What——什么是业务架构图？
个人理解：业务架构图是将软件所有的需求进行宏观地、系统地、抽象地描述，并通过图形的颜色以及结构设计展示出来。
-
二、Why——为什么要画业务架构图？
业务架构图是架构师与产品经理对接，将用户的需求进行宏观地，系统地，抽象地用图形进行描述，所以业务架构图的存在是非常有必要的，以业务架构图去也用户讲解软件系统的功能设计，使用户更一目了然的了解到系统的功能，便于产品经理与用户之间的沟通；另一方面，架构师以业务架构图去跟开发人员对接开发需求，是在所有基础需求的基础上进行了抽象化全局化的设计，更便于开发人员分层次地理解需求，进行模块化，抽象化的系统开发，实现系统的可复用性、可拓展性。
-
三、Who——由谁来做？
业务架构图是由架构师进行需求分析和业务抽象所画的。
-
四、When——什么时间（段）画？
架构图不仅仅包括业务架构图，还包括技术架构图和运维架构图等。不同的架构图在不同的阶段进行绘制：
（1）业务架构图：在产品确定需求，进行需求分析之后绘制；
（2）在业务架构图确定之后，进行技术选型，绘制技术架构图，以及初步的运维架构图
（3）系统部署上线前，完善运维架构图
-
五、How——如何画？
1.从全局上看：
（1）结构分级
- 纵向：要有分层的概念，整体上要有层次感，上层依赖于下层，越底层，越是基础服务，更为重要；
- 横向：并列结构，同级别；
- 对称：要讲究对称美，尽可能地功能结构分配均匀；
- 虚线框和实线框的使用：多个模块，逻辑上可以归为一块时可以使用虚线框；
（2）色彩搭配
- 颜色搭配要有所区分，不同层级、不同类型要颜色不同，但是也不能太跳脱，整体上颜色风格要一致，整体上要符合大众的审美风格。
2.从局部上分析：
- 大小、格式：要注意大小一致，格式统一；
- 模块划分粒度：细节要进行抽象，抽象出模块，模块的粒度要合适，不可太具体，也不可太宽泛；
- 模块分级摆放：同一个级别的模块要统一级别，粒度大小要统一；
- 词汇描述：要用词准确，可以让开发人员或者用户理解描述的意思
- 命名统一：命名上要统一，英文名体现专业性，命名要尽可能使用短名称且一致；
总结
画架构图的最大原则：让别人能看的懂，理解的明白！
业务架构图实例
v1.0 第一版：
此版本存在的问题：
第一点就是整体上不对称，有上有前端界面，下无基础服务；
第二点就是业务太具体化，没有抽象，没有全局化，开发人员如果按照这样的架构图进行开发，开发的业务太具体，一定不符合依赖倒置原则，每一个功能业务都是固定的，不易拓展，不可复用。
......
V 7.0版本：
大家可以明显的看出来这一版和第一版相比，有很大的变化。
此版本：
外观上结构对称，色彩由浅入深且风格统一，大小格式对称统一；
业务上进行抽象，符合依赖于抽象不依赖于具体，进行模块划分，将模块间的耦合度降到最低，尽可能的抽象，使得开发的业务模块可复用、可拓展。
从V1.0第一版到V7.0版本，我们经过了至少7版的迭代和完善，大家可以自己思考一下如果你是架构师，如何将第一版的具体业务需求进行抽象封装，一步步的绘制符合软件开发要求的可复用、可拓展的业务架构图？（留给大家思考一下）
总结：
任何事情永远没有最好，只有更好，画架构图也是一样，永远都有下一版，一直需要不断完善和更新！