【系统架构】业务架构图验收的思考

---

近日进行了项目的整体验收，首先验收的是业务架构图，针对业务架构图领导给出了指导意见，以下是个人针对业务架构图引发的一些思考。

业务架构图是什么？

业务架构图是软件设计过程中最重要的设计。处于整个系统基石的位置。其重要性可谓是重中之重。不论是后续的功能设计，还是数据库设计，都要以业务架构图为基础。从业务架构的设计成果中可以获得业务逻辑、功能需求。数据关系等重要的开发信息。能通过分层，包含等图形表示看出业务之间的关系。也是贯穿我们整个业务开发的指南针。

业务架构图是做什么的？

对用户：业务架构图使用户更一目了然的了解到系统的功能，便于产品经理与用户之间的沟通；
对开发人员：便于开发人员分层次地理解需求，进行模块化，抽象化的系统开发，实现系统的可复用性、可拓展性。

业务架构图怎么画？

宏观出发

1、整体结构的上下顺序为上级依赖于下级。
2、色彩搭配不要太唐突，最好有渐变性。
3、图形间宽松程度适宜，对称程度适宜。
4、虚线框和实线框的结合，实线框表示的关系强烈程度高于虚线框，虚线框更重于逻辑上的关联。
注意：架构图让读者看到的第一眼，应该给读者留个好印象，从色彩搭配上来看，颜色不超过5个，搭配也不能太跳脱，图的美观设计最起码要符合大众审美。第二眼看的应该是整体结构，整张图一共分为几个层次模块，架构图是不是能清晰的表达模块与模块之间的关系？包括线框的使用，虚线框与实线框的意义是不同的，使用虚线框还是实线框更能准确清晰的表达想要表达的意思。

局部细节

1、用词表达要标准
2、业务要全面
3、模块划分粒度适宜
4、模块摆放以及层级关系
5、图形间距离适中，避免间距过大、过小，影响美观。

说明：
架构图的名词表达要到位，比如：业务架构图和运维架构图中不能出现技术的字眼。因为不同架构图的读者是不同的，要保证你的读者能迅速的get 到你想表达的意思，这是很重要的。

架构图表达的内容是否全面，不管是业务，技术还是运维架构图要表达的内容一定要全面，包括软件系统依赖的第三方服务等都要体现出来。

关于架构图中模块的划分粒度，一定要合适，既不能太宽泛，也不能太细粒度，要达到对具体的小功能模块进行一层抽象的粒度即可。

包括模块摆放的逻辑是否准确，架构图的每一个模块的摆放，都是有讲究的，要能说出为什么这个模块放在这？放在那行不行？为什么？能回答出这几个问题，相信你的架构图问题不大。

实例

微信业务架构

AR业务架构