第3章
架构设计

架构设计以业务理解、需求分析的成果为输入，对系统架构进行设想和描述，最终输出架构设计文档。4+1架构视图也可称为4+1视图模型，是一种软件架构设计方法，通常用于从不同的视角描述大型复杂软件系统。4+1视图模型由Philippe Kruchten于1995年提出，并在Rational Software Corporation（现在的IBM公司）的Rational Unified Process（统一软件过程）中得到广泛应用。图3-1所示为经典的4+1视图模型。

下面对几个视图进行解释。

·逻辑视图：描述系统的功能、组件和它们之间的关系。该视图主要关注系统的静态结构，包括类、接口、包和模块等，用于表示系统的组织结构、模块划分和关系。

·进程视图：描述系统的并发性和分布性。该视图主要关注系统在运行时的行为，包括系统运行时的进程、线程、节点和通信方式等，用于表示系统的并发性、分布性、通信和同步方式。

·物理视图：描述系统的部署和配置。该视图主要关注系统在物理计算资源上的部署，包括硬件、网络、服务器和存储等，用于表示系统的部署拓扑、配置和资源分配。

·开发视图：描述系统的软件开发过程。该视图主要关注软件的开发、构建和部署过程，包括开发环境、版本控制、构建工具和编译器等，用于表示系统的开发工程、构建过程和开发环境。

·场景视图：描述系统在不同情景下的使用场景。该视图主要关注系统的用例、用户交互和系统行为，包括用户界面、用例场景和用户需求等，并用于表示系统的功能需求、用户交互和系统行为。

4+1视图模型存在以下问题。

1）时代局限性

4+1视图模型是1995年提出的。1995年，Windows 95刚刚发布，Java语言刚刚诞生，互联网尚未普及，浏览器也刚刚出现，软件系统采用的是单一技术的单体应用，且运行在少量几台机器上，与现在的大型信息系统在技术复杂度、业务复杂度、开发规模、用户规模、部署规模上都无法比较。在这种技术背景下，整个方法论考虑的面比较狭窄，仅适用于单机应用或简单的C/S结构和B/S结构的应用系统。

2）描述充分性

对于大中型项目来说，描述系统架构仅仅用几个视图是远远不够的。图虽然易于理解，但表达的信息量有限。为了描述完整的架构设计，还需要使用大量的文字来说明设计思路，以及使用大量的表格来进行信息整理、比较分析。最终将所有的图、表格和文字组织在一起，才能形成完整的架构设计文档。

3）逻辑视图问题

逻辑视图是在软件层面对系统进行初步分解。由于提出4+1视图模型时软件系统大部分为单体应用，采用单一技术，在技术上没有多少可以考虑的，因此如果对系统进行分解，不可避免地就要考虑这个单体应用的程序结构，结果就到了类、包、模块的粒度。现在的大中型项目甚至小型项目一般都不再是单体应用，而是由很多组件构成的分布式应用，因此需要在组件维度对系统进行分解，在组件层面考虑可复用性、技术选型，而对每个组件内部的代码结构暂不考虑。总体而言，在软件系统复杂化后，对系统分解的主视角发生了变化，从代码结构变成了组件划分，所以4+1视图模型中的逻辑视图其实已经不再适用。

4）开发视图问题

经过组件划分后，所有组件可以分为复用组件和开发组件。对于每个要开发的组件，确实有必要确定其工程结构，但是对于一个有一定积累的软件组织来说，代码工程的框架是可以直接复用的，并不是每个项目都要考虑。开发语言、开发工具、框架、过程支撑工具也都是固定的，不需要每个项目都考虑，因此开发视图中涉及的内容其实没有多少需要考虑。在架构设计的第一视角变成组件后，更重要的其实是定义组件与代码工程的对应关系，至于每个代码工程的内部结构，可以延后考虑，不在系统架构设计的考虑范围内。

5）进程视图问题

在系统复杂度提升、第一视角变成组件后，进程逐渐被弱化，如果要考虑进程也是对每个组件分别考虑，至于每个组件由几个进程组成，线程模型如何设计，可能到开发阶段才需要考虑。首先要考虑的其实是各个组件之间如何通信，这种通信不是进程间通信，而是网络通信，涉及通信协议、传输格式和通信框架的选择。

6）物理视图问题

这里把部署视图当成物理视图，但“物理”一词的含义并不明确，如果是指硬件，就没有软件什么事，只展示服务器即可；如果是指软件到硬件的映射，就是部署，此时不应该用“物理”一词。之所以出现“物理”一词，很可能是为了与“逻辑”对应。

7）场景视图问题

场景视图是用例，属于功能性需求，是在做架构设计之前就应该确定的。在架构设计阶段，需求是输入，架构师需要对需求进行确认，而不是在这个阶段考虑需求。

8）几个视图的关系不明

几个视图是从不同角度来考虑问题的，这几个视图相互之间有何关系呢？可以尝试用领域模型来理解4+1视图模型，如图3-2所示。当系统是小型的且由一个单体应用构成时，该应用就是系统的全部，应用的架构即系统架构。系统需求对应场景视图，应用的代码工程对应开发视图，设计的类对应逻辑视图，部署的机器对应物理视图，运行的进程对应进程视图。架构设计是围绕单体应用、代码工程、类、机器和进程这几种元素展开的，架构设计范围是图3-2中虚线框选的部分。

当系统为大中型时，可复用性被提升到一个较高的高度，系统将由很多组件构成，其中一部分是复用的，一部分是要开发的，系统架构要考虑的首先是这些组件的划分和技术选型，而不再是某个组件的内部结构。大中型系统架构设计领域模型如图3-3所示。其中，第一层级要考虑的内容变成组件构成。另外，需求作为输入，不纳入架构设计范围内。设计的类由于层级降低且与业务功能关联密切，因此不在架构设计范围内。

本书要讲的架构设计方法采用的是图3-3中的思路，以组件驱动，首先对系统划分组件并定义其关系，然后基于组件划分的结构来定义技术要素。整个设计分为逻辑架构设计和物理架构设计两个阶段。这里的逻辑和物理分别指抽象和具体，类似于面向对象编程中先定义一个抽象类，再编写一个具体的实现类。其实很多设计都分为逻辑设计和物理设计两个阶段，如系统工程、数据库工程等。分为这样两个阶段有一大好处，就是先通过抽象的逻辑设计可以尽快确定相对稳定的总体结构，再在这个基础上做进一步的设计就会比较清晰，在物理架构设计中针对逻辑架构的元素逐一具体化就可以得到最终设计。有的书将物理架构当成服务器视图或部署架构，这是一种错误的理解，读者需要注意。 2EixumyEF1BXi0VBR+wBJ+9UV1UHa4JHRiygDd7nSXUGiFydB8kSjmBUUIlDmHzd