1.1　对各种架构的解释

在软件行业中，“架构”这个词出现的频率很高，大家可以看到带有各种定语的架构，如企业架构、系统架构、软件架构、业务架构、数据架构、部署架构、功能架构、技术架构、开发架构、基础设施架构、逻辑架构、物理架构等。在谈及某种架构时，一定要搞清楚讨论的是哪种架构。下面介绍不同种类架构的含义。

1.软件架构

软件架构的含义比较模糊，范围可大可小。狭义的软件架构是指单个程序的结构，一般认为软件架构是指系统中纯软件部分的架构；广义的软件架构是指整个系统的架构。在谈及软件架构时，一定要结合上下文来界定它的含义。图1-1所示为一般意义上软件架构的考虑内容，从总体上来看考虑的是应用程序的代码结构。如果程序是使用面向对象编程语言实现的，则考虑的是类的属性、类之间的关联、一些方法的调用关系等；如果程序是使用结构化编程语言实现的，则考虑的是文件构成、函数调用关系等。

2.系统架构

系统的全称是信息系统。系统架构考虑的内容如图1-2所示。系统是一个由人、地点、软件、硬件、网络等元素构成的有机整体，通过不同元素之间的交互，持续运转某些业务。在研究系统架构时，不仅要考虑软件的构成，还要考虑各个元素的构成和相互之间的关系。在元素的构成中，人可以分为多种角色，软件可以分为多个组件，硬件可以有服务器、终端设备、外设等，系统的前后端会涉及多个地点，系统可能会在多个网络上进行通信。在系统架构中，各个元素之间存在一定的关系，其中人和硬件会位于某些地点，人使用软件，软件运行在硬件之上，硬件连接网络，软件要通过网络与其他软件通信。由此可见，系统架构的考虑范围远大于软件架构。系统架构考虑的是整个系统所有方面的问题。本书讨论的正是系统架构，主要描述系统中各个元素的构成及相互关系。

3.企业架构

企业架构并不是指单个系统的架构，一家企业要在信息化时代良好运转，需要多个信息系统的支撑。企业架构以业务为导向，分析需要哪些系统来支撑，要用到什么技术，需要哪些数据，最终得出的是宏观的规划，说明需要构建哪些系统，如何支撑其业务运转。企业架构开发总的来说是一项规划性质的工作，通常由熟悉TOGAF方法论的咨询公司来承接，中小型软件企业一般不具备开发企业架构的能力。软件企业的架构师通常不需要掌握企业架构方法论，因为这和单个系统的架构不是一回事。

4.业务架构

业务架构是企业治理结构、商业能力与价值流的正式蓝图。业务架构明确定义企业的治理结构、业务能力、业务流程和业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。

5.技术架构

技术架构其实是较为随意的说法，没有权威的定义，一般理解为系统架构中纯技术的部分，是相对于业务架构而言的。广义的技术架构应该包括系统中所有的技术要素，狭义的技术架构有时仅指技术选型。

6.数据架构

数据架构是指对数据进行组织、设计和管理的过程，包括数据模型、数据结构、数据流和数据处理流程等。它是一个系统性的、结构化的、可重用的框架，用于实现数据的有效管理、存储、处理和分析。

7.部署架构

部署指的是将软件制品安装到各种硬件上并运行起来，直至整个系统可提供服务的过程。实际上的部署还有之前的几个环节，即选择机房、将硬件安装到机房或直接向机房申请运行环境、连接网络及配置网络。完整的部署架构应包含以上所有内容，有时说的部署架构较为狭义，仅指软件到硬件的映射关系。

8.功能架构

在初步描述对系统的构想时，往往先绘制功能架构图（多数架构师都会绘制的一种图）。功能架构通常以分层的方式将系统的功能模块进行罗列，是初步理解系统能做什么的一种表现形式。需要注意的是，功能架构图中出现的元素都是功能模块，而非系统组件，组件和功能是对系统进行分解的两种维度。

9.开发架构

开发架构的含义较为明确，指的是系统软件中需要开发的部分所对应的代码结构，一方面是代码工程结构，另一方面是在各个工程中代码如何分层、类结构如何设计等。

10.基础设施架构

构成系统的各种软件组件要想运行，需要基础设施来支撑，硬件、网络、虚拟化平台、容器平台都属于基础设施的范畴。基础设施如何支撑其上运行的软件，以及保证软件的可用性、性能、安全性和可伸缩性是基础设施架构要研究的内容。

11.逻辑架构

逻辑架构指的是在概念上将系统分解成若干组件，这些组件是抽象的，并且以母语命名，意在说明各个组件的职责和关系，不涉及具体技术和实现。

12.物理架构

将逻辑架构转换成具体实现就是物理架构。有人认为物理架构等同于部署架构，绘制的架构图就是服务器视图，这是错误的。因为逻辑和物理对应的分别是抽象和具体，如果把物理架构当成服务器之类的，就不是从抽象到具体，而是转换了一个视角，这样会比较突兀，不是正常的循序渐进的设计思路。

以上是对各种架构的解释，需要注意的是，国家计算机技术与软件专业技术资格（水平）考试对架构师的正式称呼是系统架构设计师，并且对系统架构设计师的要求如下： 能够根据系统需求规格说明书，结合应用领域和技术发展的实际情况，考虑有关约束条件， 设计正确、合理的软件架构，确保系统架构具有良好的特性；能够对项目的系统架构进行描述、分析、设计与评估；能够按照相关标准编写相应的设计文档； 能够与系统分析师、项目管理师相互协作、配合工作；具有高级工程师的实际工作能力和业务水平。

作者认为，无论是对系统架构设计师的工作输入、自身职责还是周边关系的定义，上述要求都是比较合理的，符合大中型项目对系统架构设计师的实际要求。本书面向的正是系统架构设计师，讲述的正是系统架构设计的通用方法和描述框架，对应上述要求中带下画线的部分。这里所说的系统是指单个具有一定规模和复杂度（包括业务复杂度和技术复杂度）的信息系统，其形式可以是标准化产品、解决方案项目、自运营系统。 XJpd3dpXRnMVbIs6SBRqhRyEmpf8eSauRrx4AZ9xOzgkUYy4Fs8rK1Wwxk/ALSyW