软件架构的4+1视图介绍、应用和闲聊（附：架构设计文档目录参考）

阳光不锈@

已于 2024-02-29 10:25:19 修改

阅读量1.4k

点赞数 11

文章标签： 4+1视图架构视图介绍与应用架构设计文档目录参考

于 2023-12-01 12:34:59 首次发布

本文链接：https://blog.csdn.net/qq_35207086/article/details/134730920

版权

写在前面的话

首先，软件架构4+1视图（how问题）是软件架构设计的方法论，我们在撰写软件架构设计说明书时经常采用。

那什么（what问题）是架构呢？架构按照IEEE描述来说，架构描述了一个系统的基本组织结构，包含了组成系统的组件、组件之间的关系、组件与环境之间的关系，以及指导上述内容进行设计和演化的原则。

系统
组织起来完成一系列功能的组件集
组件
组件是一个系统模块化的某部分，从设计角度来理解组件其实就是一系列功能集的封装体。
环境
环境或上下文，指的是会地这个系统的开发、运行等造成影响的环境和设置，比如：政策法规、软硬件环境等，是一些软件系统之外的因素。

那什么（what问题）是架构设计呢？软件架构设计指的是：对一个软件系统进行的架构定义、文档编写、维护和改进、并验证实现的一系列过程。我们可以看出架构设计并不是画几张图、描述一下就行了，也并不是“ppt架构”。架构设计的产物就是一个系统的架构。

其次，我想问：为什么（why问题）要进行软件架构设计呢？（自己可以先想想），不做架构设计系统就不能运行吗？不是。做了架构设计，开发维护就变得很容易了吗？也不是。那架构设计应该就是促进业务发展？可能也不是。那不经问一句做架构设计图的是啥？

可能你会说以下几个原因：

（1）项目流程要求做架构设计

（2）为了高可用、高性能、高并发和可扩展

持第一个观点的人，我想说不能生搬硬套已经存在的架构，本来很简单的小系统，非要去匹配适应架构，起不到作用，还浪费时间和精力。

持第二种观点的人，我想说“三高”是架构设计带来的好处、并不是目的。总是喜欢一上来就是微服务、分布式、消息队列、缓存，可能会导致原本简单的系统复杂化。

那架构设计图啥呢？

并不是标准答案，但我认同这种说法：架构设计为了解决降低业务复杂度。

问：例如：业务是不是7*24小时服务？应该选用什么架构？

答：如果业务是7*24小时办理，应选择高可用、可扩展、容错能力强的架构，比如：微服务架构，用到负载均衡、数据库分片分区，或者数据库冷热分离、容错技术和自动化运维，这就是适合业务7*24小时的业务场景。

还比如说高峰期一秒钟有多少笔业务？每年的业务量有多大？未来两年业务增长很快吗？业务访问权限很严格吗？不通的回答就能确定选择不同的架构，优先保障需求满足的点，这才是架构设计的目的所在。

1、架构分类

架构没有统一标准，事实上业界对架构并没有统一的分类标准，我们也看过很多架构分类方式，总结起来大体有这样一些。

有按实现层次划分的、有按关注方向划分的，有按软工阶段划分的，有按视图类型划分的，有按技术实现风格划分的等等，这些分类有很多是交叉重叠的。

1.1 按实现层次划分

移动架构：在移动端这边的架构，从早期MVC架构形式到MVP，MVVM，MVC等等架构形式。虽然这些架构形式在不断变化，但是对于它的本质一直是没有变的，对于MVX系列的设计它的本质都是关注点分离，还有做高内聚，低耦合，基本都是围绕这个思路在演化架构的形式。
前端架构：不管是android、IOS，H5还是微信小程序统称大前端，它的架构形式有相似之处，一般来说会为前端专门做一个后端来公用，也就是它的支撑能力同时满足多端需要。
系统架构
应用架构：完整系统组成结构，比如说把这个系统分成几个部分，每个部分都干些什么事情，然后把每个功能进行细分，最后把整个系统功能分成逻辑功能模块，并且看起来是科学、合理的，那这个组成起来就是业务上的系统架构。
技术架构：从技术方向上来看，主要是技术层面的东西来描述系统。比如说做一个单体应用架构还是一个分布式应用架构，亦或是一个微服务架构等等，还有包含分层模型、领域驱动模型（DDD），比如说做表现层、应用层、持久层，甚至加入缓存层、静态资源层等。包括每一层具体使用哪些技术框架，比如是spring、hibernate、springmvc，使用哪些成熟的类库，中间件等等。当然还要考虑到系统如何去部署，如何支持分布式，如何实现高可用、高稳定性、健壮性和高性能，包含能够灵活扩展、安全性等等一系列问题。这些问题全部都放在技术架构方案里面，这个也是我们未来做架构设计一个非常重要的方向。
平台架构：指在实现一个业务系统采用的基础平台，一般来说平台架构和业务是无关的，是可重用的部分，可以是第三方开源或商用的，也可以是公司自建的平台。例如做微服务可选的是spring boot + spring cloud这一套。
应用集成架构：指如何集成第三方或遗留系统，具体以怎样的形式去做，要有一套自己的调用机制，比如通讯方式等等。
数据库架构：库表、还有表之间的关系，库该如何拆分，要不要集群，几主几从等。
存储架构：数据介质选择，存在哪个地方，灾备机制
网络架构：网络设备、广域网如何接入等

1.2 按关注方向划分

业务架构：指支撑业务的技术架构，要从业务和商业的角度看。
应用架构
技术架构
开发架构：从具体的实现角度来看，比如选用什么样的框架，代码规范等
数据库架构
存储架构
安全架构：基础设施安全，防火墙，应用系统安全，数据安全，防重放机制，传输安全
部署架构：应用开发完之后发布到哪几台机器上，比如这台放应用，那台放数据库等等
开放架构：OpenAPI架构，比如百度、京东、天猫的开放接口

1.3 按软工阶段划分

解决方案架构：在项目立项初期跟客户进行浅层次交流的时候，我们可能根据用户关注的问题输出一些解决方案，主要是一些概要性的架构设计，或者是根据用户关注的技术点做的一些设计。
业务架构
系统架构
概念架构：是指组件及其之间的交互，那么这些构成的就是概念架构，通常不涉及接口细节。
细化架构：就是对概念架构进行细化，细化到具体的模块、功能和接口，甚至是具体的实现类上，那么一层一层的把概念架构落地。
平台架构
开发架构
部署架构
运维架构：实际上是从运维的角度来看，我不仅仅知道你要部署到多少台机器上，还要对这些东西进行监控、管理，比如重启、替换和数据迁移等工作。

1.4 按视图类型划分（4+1视图模型）

逻辑架构：对整个系统进行每一级的划分，然后划分子系统、模块和组件，以及定义接口相互之间的关系。
数据架构：与数据库架构略微有一点不同，它关注数据的存储、分布、访问以及数据本身的安全等等，包括未来数据怎样备份、扩容。
开发架构
运行架构：考虑系统在运行期间的一些质量属性，比如说性能怎么样，可伸缩性怎么样，持续可用、易用性，运行起来的线程数，对资源的消耗，包括并发、同步和通讯问题。
物理架构

1.5 按技术实现风格划分

分布式架构：通过业务分散，远程调用的一种形式
分层架构：现在纯粹分层已经很少用了，但是我们在某一个功能块里面还是会用到，比如说分表现层、数据层
事件驱动架构：纯粹的事件驱动也比较少见，可能会在复杂的架构中有一部分看到事件驱动这种方式。
微内核架构
微服务架构：把功能包装成一个一个微服务，当然这个需要对功能进行合理的划分，这个拆分要合理，每个服务相对独立，向外去提供功能。
SOA架构
响应式架构

2、软件架构的4+1视图模型发展过程

1.首次提出

1995年11月 Philippe Kruchten发表于《IEEE Software》的论文《The 4+1 View Model of Architecture》首次提出如图所示的4+1视图，分别为：逻辑视图、开发视图、过程视图、物理视图和场景视图。

其中，

（1）逻辑视图的利益相关人是最终用户，关注点是系统的功能，系统应该向用户提供什么服务。（使用：可使用类图来描述）

（2）开发视图（实现视图）的利益相关人是开发人员和项目经理，关注点是组织，可复用性，可移植性，产品线。对于非常小的系统，逻辑视图和开发视图可能几乎是一样的，那就没必要分开来描述。（使用：可使用组件图来描述）

（3）过程视图（流程视图）的利益相关人是系统设计人员和集成人员，关注点是一些非功能需求，例如：性能，可用性，软件容错，完整性。从逻辑视图可以分析出有哪些进程，可以用文字进行描述，可不用画出图形。如果只有一个处理器而且只有一个进程或者程序时，可以省略过程视图（使用：文字描述、序列图、活动图、状态图等方式来进行展示）。

（4）物理视图（部署视图）的利益相关人是系统设计人员，关注点是可扩展性、性能，可用性。它是建立软件和硬件的映射关系，考虑系统的非功能需求。（使用：可使用部署图进行展示）

注：可以看到过程视图和物理视图关注点是有点相似的，都是关注系统的非功能需求，比如性能、可用性等，但是他们考虑的方法和角度是完全不一样的，过程视图考虑的是对系统的进程进行分解，要设计哪些进程，哪些对象要放在哪些进程来运行，通过这样的方式来提高系统的性能和可用性的问题。而物理视图考虑的是把哪些软件部署在哪些硬件上，来解决系统的性能和可用性问题。

（5）场景视图的利益相关人是最终用户、开发人员，关注点是可理解性。场景是最重要的需求的抽象。（使用：可使用用例图描述）

2.演变

演变后，只是更详细和具体了，逻辑视图和过程视图没有变、开发视图变为实现视图，物理视图变为部署视图，场景视图变为用例视图。

3.视图之间的关联

3.1从逻辑视图到过程视图

逻辑视图关系系统的功能，具体就是识别对象与对象的关系，从逻辑视图到过程视图，就是识别对象的并发。

3.2从逻辑视图到开发视图

逻辑视图本身识别出了系统的对象和类，开发视图就是在逻辑视图的基础上，通过类来识别系统模块和子系统，以及模块和子系统之间的关系，从而形成开发视图。

3.3从过程视图到物理视图

4.裁剪模型

不是所有的软件架构都需要完整的4+1视图，架构描述时可以将没什么用的视图省略掉，例如：如果只有一个处理器而且只有一个进程或者程序时，可以省略过程视图。对于非常小的系统，逻辑视图和开发视图可能几乎是一样的，那就没必要分开来描述。

但是场景视图在任何情况下都是有用的。

5.总结

视图	逻辑	过程	开发	物理	场景
组件	类	任务	模块，子系统	节点	步骤，脚本
连接器	关联，继承，包含	Rendez-vous，消息，广播， RPC，等等	编译依赖, "with" 子句， "include"	通信介质，局域网，广域网，总线，等等
容器	类的类别	进程	子系统（库）	物理子系统	Web
利益相关人	最终用户	系统设计人员，集成人员	开发人员，项目经理	系统设计人员	最终用户开发人员
关注点	功能	性能，可用性，软件容错，完整性	组织，可复用性，可移植性，产品线	可扩展性性能，可用性	可理解性
工具支持	Rose	UNAS/SALE DADS	Apex, SoDA	UNAS, Openview DADS	Rose