目录
笔者最近有幸参加架构师培训的课程,在纪老师的指导下, 第一阶段已经圆满结束,第一阶段内容重点是:
-
在培养大家《面向对象的编程思想》以及《软件设计原则》的落地实现方案。
-
借助《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版的迭代和完善,大家可以自己思考一下如果你是架构师,如何将第一版的具体业务需求进行抽象封装,一步步的绘制符合软件开发要求的可复用、可拓展的业务架构图?(留给大家思考一下)
总结:
任何事情永远没有最好,只有更好,画架构图也是一样,永远都有下一版,一直需要不断完善和更新!