企业架构包含业务架构和 IT 架构两个部分。本文介绍了 IT 架构设计中的"4+1"视图模型。"4+1"视图模型诞生于上个世纪 90 年代，至今对我们进行业务架构到 IT 架构的映射仍然具有指导和借鉴意义。

“4+1”架构模型概述

软件架构用来设计和实现软件的高级结构。它将一定数量的架构元素组装成一些精心选择的形式， 以满足系统的主要功能和性能需求，以及其他一些非功能需求，如可靠性、可伸缩性、可移植性和可用性。

Perry and Wolfe 用以下模型表达软件架构：

软件架构= {元素、关系矩阵、基本原理/约束}

软件架构处理元素抽象、分解和组合、软件风格和 UI 美学。为了描述一个软件架构，我们使用了一个由多个视图组成的模型。为了最终解决大型和具有挑战性的架构，我们提出的模型包括五个主要视图： 

• 逻辑视图，即设计的对象模型 (当使用面向对象的设计方法时) ；

• 流程视图，它捕获了设计的并发性和同步性方面；

• 物理视图，它描述了软件到硬件上的映射，并反映了其分布式方面；

• 开发视图，它描述了软件在其开发环境中的静态结构(系统和应用)。

对架构的描述——所做的决策——可以围绕这四个视图进行组织，然后通过一些选定的用例或成为第五个视图的场景(注 1)进行说明。

逻辑架构

---面向对象的分解

逻辑架构主要支持功能需求，也就是系统应该为其用户提供的服务。系统被分解为一组关键抽象元素，这些抽象元素来自问题域，以对象或对象类的形式获取。对象利用了抽象、封装和继承的原则。这种分解不仅是为了进行功能分析，而且还可以用于识别在系统的各个部分之间的通用机制和设计元素。

逻辑架构视图的样式：

逻辑架构视图使用 Ratioon/Booch 方法，通过类图和类模板来表示。

类图显示了一组类及其逻辑关系：关联 、泛化、组合、聚合、继承等等。相关的类可以分组为类别。

类模板专注于每个单独的类；它们强调主要的类操作，并识别关键的对象特征。如果定义对象的内部行为很重要，则可以通过状态转换图或状态图来完成。在类功能中定义了公共机制或服务。

图中设备信息是个类模板，电子设备和机床设备这两个类泛化（或抽象）为设备信息。

除了面向对象的方法(OO)方法，数据驱动的软件应用可以使用其他形式的逻辑视图，如著名的 E-R 图。

流程架构

----流程分解

流程架构(注 1)考虑了一些非功能的需求，如性能和可用性。它解决了并发性和分布、系统完整性、容错问题，以及逻辑视图的主要抽象元素如何适合流程架构---通过线程控制来执行对象的操作。

流程架构可以在几个抽象级别上进行描述，每个级别都处理不同的问题。在最高级别上，流程架构可以被看作是一组独立执行的通信程序的逻辑网络 (称为“流程”) ，分布在由局域网或广域网连接的一组硬件资源上。多个可同时的逻辑网络存在，共享相同的物理资源。例如，独立的逻辑网络可用于支持在线操作系统与离线系统的分离，以及支持软件的模拟或测试版本的共存。

流程是构成一个可执行单元的一组任务。任务是一个单独的控制线程，可以单独调度在一个处理节点上。

流程表示流程架构可以被战术控制的级别(例如, 已启动、已恢复、重新配置和关闭)。在此外，还可以复制流程，以增加处理负载的分布，或改进可用性。

任务可以分为：

• 主要任务：是可以唯一处理的架构元素。

• 次要任务:   是由于实现原因 (周期性活动、缓冲、超时等) 在本地引入的附加任务。例如，它们可以被实现为 Ada 任务，或轻量级的线程。

主要任务通过一组定义良好的任务间通信机制进行通信：同步和异步的基于消息的通信服务、远程流程调用、事件广播等。次要任务可以通过集合内存或共享内存进行通信。重大任务不得对其在同一流程或加工节点 中的配置进行假设。

流程视图的样式：

流程可以通过一个具有判断、分支和合并的任务流程图进行绘制。

图中显示了一个蓝牙智能手表健康检测系统的任务流程图。

开发架构

---子系统分解

开发架构(注 3)侧重于软件开发环境上的软件模块静态结构。软件被打包成应用程序库或子系统， 可以由一个或少数开发人员开发。

子系统被组织在一个层的层次结构中，每一层都为它上面的层提供了接口。系统的开发架构由模块和子系统图表示，显示了“export”和“import” 的关系(注 4)。只有在确定了软件的所有元素时，才能描述完整的开发架构。开发架构的管理规则包括：分区、分组、可见性。

在大多数情况下，开发架构考虑了与开发的简易性、软件管理、重用或通用性相关的内部需求，以及工具集或编程语言所施加的约束。开发视图作为需求分配的基础，用于将工作分配给团队（甚至团队组织）、成本评估和规划、监控项目进度，以推理软件重用、可移植性和安全性。它是建立产品线的基础。

开发视图的样式

开发视图通常采用分层样式。每一层都有一个明确定义的责任。设计规则是，某个子系统只能依赖于同一层或下层的子系统，以尽量减少模块之间依赖关系，并允许简单的逐层发布策略。

物理架构

--将软件映射到硬件

物理架构主要考虑了系统的非功能需求，如可用性、可靠性 (容错性) 、性能 (吞吐量) 和可伸缩性。软件在计算机网络或物理设施 (或简称节点) 上执行，确定的各种元素——网络、流程、任务和对象——需要映射到各个节点上。

节点使用不同的物理配置：一些用于开发和测试，另一些用于为不同的站点或不同的客户部署系统。因此，软件到节点的映射需要高度灵活，并对源代码本身的影响最小。

图中显示了一个大规模分布式集群的物理架构。

场景视图

四个视图中的元素通过使业务场景视图或用例图无缝地协同工作。业务场景在某种意义上是对最重要需求的抽象。场景视图在传统 IT 架构设计中是多余的(因此是“+1”) 。

场景视图有两个主要目的：

• 作为在架构设计流程中发现架构元素的驱动因素和需求；

• 作为在此架构设计完成之后的验证。

图中显示了一个通过用例图绘制的场景视图。

未完待续...

译者注：

注 1：第五个视图正是我们的业务架构中常用的业务场景视图，而业务场景视图可以用其他业务建模方式如用户故事地图、事件风暴、业务用例视图来替代。

注 2：此处的流程非业务流程，而是指 IT 架构中的信息流和数据流，对应 PCF 中 L3 以下的流程。

注 3：此处的开发架构对应 IT 架构中的应用架构。

注 4：export 用于对外输出本模块变量的接口（一个文件可以理解为一个模块）。import 用于在一个模块中加载另一个含有 export 接口的模块。

本文内文翻译自 Philippe Kruchten 在 1995 年在 IEEE  Software 上发表的一篇文章《Architectural Blueprints—The “4+1” View Model of Software Architecture》，为便于阅读，有删节。配图来自网络。

欢迎关注涛哥微信公众号“架构领导力”和视频号“涛哥-数字产品和商业架构”