软件架构风格

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式，作为“可复用的组织模式和习语”，为设计人员的交流提供了公共的术语空间，促进了设计复用与代码复用。
架构风格的基本属性：设计元素的词汇表；配置规则；元素组合的语义解释以及使用某种风格构建的系统的相关分析
优势：

可以极大地促进设计的重用性和代码的重用性，并且使得系统的组织结构易被理解。
使用标准的架构风格可较好地支持系统内部的互操作性以及针对特定风格的分析

数据流风格

数据到达时激活，无数据时不工作

批处理风格

基本组件：独立的应用程序
连接件：某种类型的介质，完整的数据
特点：

近乎线性
每个处理步骤都是一个独立的程序
每一步在前一步结束后才开始
数据必须是完整的，以整体的方式传播

管道-过滤器风格

应用场景：数据源源不断地产生，系统需要对这些数据进行若干处理(分析、计算、转换等)。
基本组件：过滤器(功能模块)
连接件：管道(数据流)
过滤器的特点：独立性

过滤器独立完成自身功能，相互之间无需进行状态交互。
过滤器自身无状态
过滤器对其上下游的过滤器“无知”

管道的特点：

管道的作用：将数据从一个过滤器的输出口转移到
另一个过滤器的输入口
管道是单向流动的。
管道可以有缓冲区。

结果的正确性不依赖于各个过滤器运行的先后次序
管道—过滤器风格优点：

由于每个组件行为不受其他组件的影响，整个系统的行为易于理解。隐蔽性，高内聚低耦合
管道-过滤器风格支持功能模块的复用。
基于管道-过滤器风格的系统具有较强的可维护性和可扩展性。
支持一些特定的分析，如吞吐量计算和死锁检测等。
管道-过滤器风格具有并发性

缺点：

管道-过滤器风格往往导致系统处理过程的成批操作。
根据实际设计的需要，设计者也需要对数据传输进行特定的处理（如为了防止数据泄漏而采取加密等手段，或者使用了底层公共命名），导致过滤器必须对输入、输出管道中的数据流进行解析或反解析，增加了过滤器具体实现的复杂性，系统性能不高。
交互式处理能力弱

调用/返回风格

主程序/子程序风格

该架构风格从功能的观点设计系统◦ 通过逐层分解和逐步细化得到系统架构，即将大系统分解为若干模块(模块化)，主程序调用这些模块实现完整的系统功能。主程序的正确性依赖于它所调用的子程序的正确性。
组件为主程序和子程序，连接件为调用-返回机制，拓扑结构为层次化结构。

优点：

结构化程序设计的典型风格，相对于非结构化设计逻辑清晰，易理解。
开发过程采用逐步细化，将大系统分解为若干模块（模块化）。

缺点：

对数据存储格式的变化将会影响几乎所有的模块。
结构化程序在规模变大时会难理解、难测试、难维护。
这种分解方案难以支持有效的复用。随着程序规模的增大，大量函数、变量之间的关系错综复杂，要抽取可重用的代码往往变得十分困难。

面向对象风格

组件：管理器
连接件：过程调用
约束：去中心化，通常是单线程
优点：

对象隐藏了其实现细节，所以可以在不影响其它对象的情况下改变对象的实现，不仅使得对象的使用变得简单、方便，而且具有很高的安全性和可靠性。
设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

缺点：

大量对象需要额外的结构化。当系统中有大量的对象时，需要额外的结构来组织这些对象，以便更好地管理和理解它们
管理大量交互。
行为的责任分布使系统难以理解。当行为的责任分布在多个对象和类之间时，系统的逻辑可能会变得复杂，难以理解和维护。例如，一个对象的行为可能依赖于多个其他对象的状态和行为。

层次化风格

基本思想：在分层系统（Layered System）中，系统被组织成若干个层次，每个层次由一系列组件组成；层次之间存在接口，通过接口形成call/return的关系——下层组件向上层组件提供服务，上层组件被看作是下层组件的客户端。
在分层架构中，组件被划分成几个水平层，每个层在应用中执行特定角色。
组件：通常是复合体；复合体通常是由一系列程序组成的
大多数分为四个标准层：表现层，业务层，持久层，数据库层
连接件：取决于组件的结构；经常在受限可见性下调用过程
约束：单线程
特点：

分层架构中的每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。

优点：

支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
支持扩展。每一层的改变最多只影响相邻层。
支持重用。只要给相邻层提供相同的接口，它允许系统中同一层的不同实现相互交换使用。

缺点：

不是所有系统都容易用这种模式来构建。
定义一个合适的抽象层次可能会非常困难，特别是对于标准化的层次模型。
层层相调，影响性能

客户机/服务器风格(C/S)

客户机和服务器是两个相互独立的逻辑系统，为了完成特定的任务而形成一种协作关系。
客户机(前端，front-end)：业务逻辑、与服务器通讯的接口；
服务器(后端：back-end)：与客户机通讯的接口、业务逻辑、数据管理。

两层C/S风格

优点：

客户机组件和服务器组件分别运行在不同的计算机上，有利于分布式数据的组织和处理。
组件之间的位置是相互透明的
客户机程序和服务器程序可运行在不同的操作系统上，便于实现异构环境和多种不同开发技术的融合。
软件环境和硬件环境的配置具有极大的灵活性，易于系统功能的扩展。
将大规模的业务逻辑分布到多个通过网络连接的低成本的计算机上，降低了系统的整体开销。

缺点：

开发成本较高（客户机的软硬件要求高）。
客户机程序的设计复杂度大，客户机负荷重。
信息内容和形式单一。
C/S架构升级需要开发人员到现场更新客户机程序，对运行环境进行重新配置，增加了维护费用。
两层C/S结构采用了单一的服务器，同时以局域网为中心，难以扩展到Internet。
数据安全性不高，客户端程序可以直接访问数据库服务器。

三层C/S风格

相比两层C/S的优点：

合理地划分三层结构的功能，可以使系统的逻辑结构更加清晰，提高软件的可维护性和可扩充性。
在实现三层C/S架构时，可以更有效地选择运行平台和硬件环境，从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性。
在C/S架构中，可以分别选择合适的编程语言并行开发。
系统具有较高的安全性。

但使用时需要注意2个问题：

如果各层之间的通信效率不高，即使每一层的硬件配置都很高，系统的整体性能也不会太高。
必须慎重考虑三层之间的通信方法、通信频率和传输数据量，这和提高各层的独立性一样也是实现三层C/S架构的关键性问题。

浏览器/服务器风格(B/S)

与三层C/S结构的解决方案相比，B/S架构在客户机上采用了WWW浏览器，将Web服务器作为应用服务器。
B/S架构核心是Web服务器，数据请求、网页生成、数据库访问和应用程序执行全部由Web服务器来完成。
在B/S架构中，系统安装、修改和维护全在服务器端解决，客户端无任何业务逻辑。
优点：

客户端只需要安装浏览器，操作简单，能够发布动态信息和静态信息。
运用HTTP标准协议和统一客户端软件，能够实现跨平台通信。
开发成本比较低，只需要维护Web服务器程序和中心数据库。客户端升级可以通过升级浏览器来实现。

缺点：

个性化程度比较低，所有客户端程序的功能都是一样的。
客户端数据处理能力比较差，加重了Web服务器的工作负担，影响系统的整体性能。
在B/S架构中，数据提交一般以页面为单位，动态交互性不强，不利于在线事物处理
B/S架构的可扩展性比较差，系统安全性难以保障。
B/S架构的应用系统查询中心数据库，其速度要远低于C/S架构。

以数据为中心的风格

最初，硬件/软件系统的配置信息均被各自保存在一个配置文件中(.ini)；这些文件散落在系统各个角落，很难对其进行维护；引入注册表的思想，将所有.ini文件集中起来，形成共享仓库，为系统运行起到了集中的资源配置管理和控制调度的作用。
注册表中保存了系统的所有硬件和软件配置信息；这些信息影响或控制系统/应用软件的行为，应用软件安装/运行/卸载时对其进行添加/修改/删除信息，以达到改变系统功能和控制软件运行的目的。

仓库风格

基本思想：仓库是存储和维护数据的中心场所
组件：

中心数据结构组件，表示当前数据的状态
相对独立的组件集合，各个功能模块等

连接件：数据仓库与独立组件之间的交互
优点：

便于模块间的数据共享
方便模块的添加、更新和删除
避免了知识源的不必要的重复存储

缺点：

对于各个模块，需要一定的同步/加锁机制保证数据结构的完整性和一致性

黑板系统风格

一个大问题被分解为若干个子问题，每个子问题的解决需要不同的问题表达方式和求解模型，分别设计求解程序
组件：黑板，知识源，控制组件

知识源：

知识源是描述某个独立领域问题的知识及其处理方法的知识库
知识源分别存放且相互独立
他们通过黑板进行通讯，合作求出问题的解
通常知识源具有“ 条件- 动作”的形式。当条件满足时，知识源被触发，其动作部分增加或修改黑板上的内容。

控制器：

时刻监视黑板状态变化
对黑板上信息的当前状态进行判断和评价
当黑板的状态满足了知识源的执行条件时，该知识源被控制器触发并进行计算，然后将结果更新到黑板上
这种更新又导致其他知识源参与计算并更新黑板，直到找到问题解为止

优点：

便于多客户共享大量数据，他们不关心数据何时有的、谁提供的、怎样提供的。
既便于添加新的作为知识源代理的应用程序，也便于扩展共享的黑板数据结构。
知识源可重用。
支持容错性和健壮性。

缺点：

不同的知识源代理对于共享数据结构要达成一致，而且，这也造成对黑板数据结构的修改较为困难——要考虑到各个代理的调用。
需要一定的同步/加锁机制保证数据结构的完整性和一致性，增大了系统复杂度。

虚拟机风格

虚拟机是一种软件，创建了一种虚拟的环境，将用户和底层平台隔离开来。
JVM(Java Virtual Machine)可适应所有的硬件与OS平台，从而使得Java具有“一次书写，到处运行”的能力。
在JVM上运行的程序必须首先被编译为标准的二进制格式的文件：.class
Java class文件并不是机器代码或目标代码，而是一种具有标准中间格式的二进制文件，无法直接在任何OS平台上执行；Java class必须在JVM的支持下才能真正执行

解释器风格

基本思想：解释器是一个用来执行其他程序的程序，它针对不同的硬件平台实现了一个虚拟机，将高抽象层次的程序翻译为低抽象层次所能理解的指令，以弥合程序语义所期望的与硬件提供的计算引擎之间的差距。

优点：

它有利于实现程序的可移植性和语言的跨平台能力；
可以对未来的硬件进行模拟和仿真，能够降低测试所带来的复杂性和昂贵花费

缺点：

额外的间接层次导致了系统性能的下降

编译器不会执行输入的源程序代码，而是将其翻译为另一种语言，通常是可执行的机器码或目标码，并输出到文件中以便随后链接为可执行文件并加以执行

在解释器中，程序源代码被解释器直接加以执行

两者的区别：

解释器的执行速度要慢于编译器产生的目标代码的执行速度，但是却低于编译器“编译+链接+执行”的总时间
解析器执行速度之所以慢，是因为每次解释执行的时候，都需要分析程序的结构，而编译代码则直接执行而无需重复编译
解释器对内存的分配是在解释时才进行的；而编译器则是在编译时就规划好了变量的内存使用方案，因此运行时直接将程序代码装入内存并执行即可

解释器有三种策略，分别是传统解释器，基于字节码的解释器和JIT编译器
传统解释器是直接读取源代码并加以执行。
字节码解释器是首先将源代码“编译”为高度压缩和优化的字节码，但并不是真正的机器目标代码，因而与硬件平台无关；编译后得到的字节码然后被解释器加以解释
实时编译器(JIT)，字节码在运行时被编译为本机的目标代码。第一步编译得到字节码，然后，字节码被配置到目标系统中，当字节码被执行时，运行环境下的编译器将其翻译为本地机器码

基于规则的系统风格

任何规则都包含两部分：

IF部分：规则的前提或条件
THEN部分：规则的结论或触发的行为

一个规则可以有多个条件，使用AND或OR连接

优点：

降低了修改业务逻辑的成本
缩短了开发时间
将规则外部化，可在多个应用之间共享
对规则的改变将非常迅速并且具有较低的风险

独立组件风格

独立构件风格的软件系统由多个独立的组件构成，这些组件之间不共享状态，通过网络、消息队列或者其他形式的消息传递机制来进行通信和数据交换。
独立性：

组件拥有自己的内部状态和行为，组件间松耦合。
组件可以单独测试，单独部署。
组件可在不同的物理节点或进程中运行。

组件：

功能独立
为每个组件定义清晰的接口,包括输入、输出和预期行为。

连接件：

消息传递、事件驱动或远程过程调用(RPC)。
可使用中间件技术(如消息队列)来协调组件间的交互。

约束：

系统执行的过程依赖于被触发事件的上下文约束。

进程通讯：组件作为独立进程运行，通过显式通信协议直接交换数据。消息传递的方式可以是点到点、异步或同步方式及远程过程调用等。
事件驱动：组件通过发布/订阅事件隐式交互，发送者不依赖接收者的存在或响应。

进程通讯风格

进程通讯特点：

同步/异步通信
点对点交互：组件需明确知道通信对象
典型技术：REST API、gRPC、RabbitMQ

进程通讯应用场景：微服务架构、分布式计算

事件驱动风格

消息：

计算机中，消息是具有特定含义的数据
对象通过发送消息的方式请求另一个对象为其服务

事件：

能够激活对象功能的动作。当发生这种动作后将给所涉及对象发送一个消息，对象便可执行相应的功能

通常，在一个系统中，组件接口提供了访问过程或函数的端口的集合，组件通过显式地调用这些过程或函数来与其他组件交互。然而，一种基于隐式调用(implicit invocation)的集成技术非常受关注，该技术就是事件驱动(Event-based) 的软件架构风格。
基本思想：

组件不直接调用一个过程，而是发布或广播一个或多个事件。
系统中的其它组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其它模块中过程的隐式调用。

特点：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。
事件调度策略：
事件分派模块的功能：负责接收到来的事件并派遣它们到其它模块

广播式：派遣模块将事件广播到所有的模块，但只有感兴趣的模块才去取事件并触发自身的行为。
选择广播式：派遣模块将事件送到那些已经注册了的模块中。

事件驱动编程的一般步骤：
1 确定响应事件的元素；
2 为指定元素确定需要响应的事件类型；
3 为该元素的相应事件编写事件处理程序；
4 将事件处理程序绑定到指定元素的指定事件。
优点：

事件声明者不需要知道哪些组件会影响事件，组件之间关联较弱。一个组件出错将不会影响其他构件。
提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。
系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。

缺点：

组件放弃了对计算的控制权，完全由系统来决定。
存在数据交换问题。
该风格中，正确性验证成为一个问题。

其他软件架构风格

C2风格

C2风格的主要思想来源于Chiron-1用户界面系统，因此又被命名为Chiron-2，简称C2。
C2架构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行组件网络。该规则规定了所有组件之间的交互必须通过异步消息机制来实现
C2是一种基于组件和消息的架构风格，适用于GUI软件开发，构建灵活和可扩展的应用系统。
C2风格的系统组织规则：

组件之间不能直接连接
组件和连接件都有一个顶部和一个底部
组件的顶部应连接到某连接件的底部，组件的底部则应连接到某连接件的顶部
一个连接件可以和任意数目的其他组件和连接件连接
当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部

C2构件的内部，通信和处理是分开完成的
C2连接件：

连接件负责把构件绑定在一起，其上可以连接任何数量的构件和连接件
连接件的主要职责：
- 消息的路由和广播
- 消息的过滤

优点：

可使用任何编程语言开发组件，组件重用和替换易实现
由于组件之间相对独立，依赖性小，因而该风格具有一定扩展能力，可支持不同粒度的组件
组件不需共享地址空间
可实现多个用户和多个系统之间的交互
可实现多个工具集和多种媒体类型，动态更新系统框架结构

缺点：

不太适合大规模流式风格系统，以及对数据库使用比较频繁的使用

平台/插件风格

插件是一种遵循统一的预定义接口规约编写出来的程序，应用程序在运行时通过接口规约对插件进行调用，以扩展应用程序的功能。
插件的本质在于不修改程序主体(或者程序运行平台)的情况下对软件功能进行扩展与加强。
这意味着软件开发者可以通过公布插件的预定义接口规约，从而允许第三方的软件开发者通过开发插件对软件的功能进行扩展，而无须对整个程序代码进行重新编译。
“平台/插件”软件结构将待开发的目标软件分为两部分：

程序的主体或主框架，可定义为平台
功能扩展或补充模块，可定义为插件

平台所完成的功能应为一个软件系统的核心和基础，可以把平台基本功能分为两个部分：

内核功能：是整个软件的重要功能，一个软件的大部分功能应由内核功能完成。
插件处理功能：用于扩展平台和管理插件，为插件操纵平台和与插件通信提供标准平台扩展接口。

插件受到的约束：

插件必须能在运行过程中动态地插入平台和从平台中注销，且不影响系统的运行。
当在系统中插入插件后，系统的功能得到扩展或升级。
多个插件之间、插件和平台之间不会发生冲突。

实现该风格需要定义两个标准接口：

平台扩展接口：完全由平台实现，插件只是调用和使用
插件接口：完全由插件实现，平台也只是调用和使用。

优点：

降低系统各模块之间的互依赖性
系统模块独立开发、部署、维护
根据需求动态的组装、分离系统

缺点：

插件是别人开发的可以用到某主程序中的，只服务于该主程序，可重用性差

面向Agent风格

Agent组件：能够自主运行、具有某种程度的智能以适应环境变化、可以与其他Agent进行交互和通信，并且通常具备一定的目标追求能力。
Agent组件有别于以往任何系统的组件类型，其所具有的自主性、智能性、交互性等特性是传统架构对象所不具备的。
这些Agent可以是物理实体（例如机器人）或软件实体（例如在计算机网络上执行特定任务的程序）。它们通过感知周围环境，采取行动来影响该环境，并基于自身的目标和知识做出决策。
Agent连接件：对复合型组件的连接，该连接能够提供通信、协调、转换、接通等服务
多Agent系统中的连接件并非显示地将两个不同的组件联系起来。不同Agent之间的联系是根据运行时状态来决定的。
优点：

面向Agent的软件工程方法对于解决复杂问题是一种好的技术, 特别是对于分布开放异构的软件环境

缺点：

通信开销大，多Agent频繁交互可能导致延迟。
为了适应动态环境，应对复杂场景，Agent的设计比较复杂。

适用于需要处理高度动态和不确定性环境的应用场景，如自动化、电子商务、信息管理、分布式控制系统等。

面向方面软件架构风格

面向方面的编程(AOP：Aspect Oriented Programming)
系统的有些特性和需求是横切于系统的每一个层面中，并融于系统的每一个组件中，这种特性称为系统的方面(Aspect)需求特性或关注点

应用AOP的主要目的----尽量分离“技术问题实现”和“业务问题实现”：

它允许开发者能够对横切关注点进行模块化设计。
能够实现分散关注，将通用需求功能从不相关类之中分离出来。
能够实现代码重用。
方面（Aspect）：方面是横切关注点的模块化单元。一个方面可以包含与特定行为相关的建议（advice）、连接点（join points）以及切入点（pointcuts）。
建议（Advice）：指的是方面应该执行的具体动作。这可以是在特定事件发生之前（前置建议）、之后（后置建议），或者当异常抛出时执行的动作。
连接点（Join Point）：程序执行过程中的某些点，如方法调用、异常抛出等，在这些点上可以插入建议。
切入点（Pointcut）：一组连接点的集合，定义了在哪些建议应该被执行的连接点上应用。
织入（Weaving）：将方面代码整合到主程序逻辑的过程。织入可以在编译期、加载期或运行时完成。

优点：

增强功能独立性：通过分离横切关注点，使得系统更加功能独立，每个模块只需专注于其核心职责。
减少代码重复：避免了为实现相同的横切功能而在多个地方编写类似的代码。
提高可维护性：由于横切关注点被集中处理，因此更容易进行更新和维护。
简化设计：让开发者能够更清晰地表达系统的结构和行为。

缺点：

有一定学习成本
因为建议（Advice）可以改变程序流而不需要直接修改源代码，所以可能会增加调试难度。
存在潜在的性能开销，特别是在运行时织入方面时，可能会引入额外的性能成本

面向服务架构风格

SOA 是一个组件模型，它将应用程序的不同功能单元（服务）通过这些服务之间定义良好的接口和契约联系起来。

服务请求者：可以是服务或者第三方的用户，通过查询服务提供者在服务注册中心发布的服务接口的描述，通过服务接口描述来通过RPC或者SOAP进行绑定调用服务提供者所提供的业务或服务。
服务提供者：作为服务管理者和创建者，必须将服务描述的接口发布到服务注册中心才能被潜在的服务请求发现，能够为合适的服务请求者提供服务。
服务注册中心：相当于服务接口的管理中心，服务请求者者能够通过查询服务注册中心的数据库来找到需要的服务调用方式和接口描述信息。
发布：为了便于服务请求者发现，服务提供者将对服务接口的描述信息发布到服务注册中心上。
发现：服务请求者通过查询服务注册中心的数据库来找到需要的服务，服务注册中心能够通过服务的描述对服务进行分类，使服务提供者更快定位所需要的服务范围。
绑定和调用：服务请求者在查询到所需要服务描述信息，根据这些信息服务请求者能够调用服务。

优点：

灵活性，根据需求变化，重新编排服务。
对IT资产的复用。
使企业的信息化建设真正以业务为核心。业务人员根据需求编排服务，而不必考虑技术细节。

缺点：

服务的划分很困难。
服务的编排是否得当。
如果选择的接口标准有问题，如主流的Web service之类，会带来系统的额外开销和不稳定性。
对IT硬件资产还谈不上复用。
目前主流实现方式接口很多，很难统一。
目前主流实现方式只局限于不带界面的服务的共享。

微服务架构

特点：

服务自治
- 微服务围绕具体业务能力组织系统，高度内聚：
- 每个服务独立开发、部署、扩展，技术栈可异构(如Java、Python、Go)
- 各服务拥有专属数据存储
轻量级通信机制
- 同步通信：HTTP/REST、gRPC。
- 异步通信：消息队列（如Kafka、RabbitMQ）
去中心化治理：
- 服务独立演进，允许团队自治。
- 基础设施通过统一平台管理。
容错和弹性设计
- 通过熔断（Hystrix）、重试、降级等机制保障系统可用性和稳定性。

优点：

加速开发周期：团队可以并行工作于不同的服务上，加快了新功能的发布速度。
技术多样性：可以根据每个服务的需求选择最适合的技术栈。
弹性扩展：可以针对具体的服务进行扩展，而不需要扩展整个应用。
容错，易维护：单个服务宕机不会导致系统崩溃，且由于服务小并单一职责，更容易理解和维护。

缺点：

分布式系统的复杂性
运维成本高
团队协作需要严格规范接口定义

基于层次消息总线的架构风格(JB/HMB风格)

JB/HMB风格基于层次消息总线、支持组件的分布和并发，组件之间通过消息总线进行通讯。
消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回。各个组件挂接在消息总线上，向总线登记感兴趣的消息类型。不要求各个构件具有相同的地址空间或局限在同台机器上，可较好地描述分布式并发系统。
优点：

模块化与可维护性
灵活、可扩展
支持异步通信
增强了系统的容错能力

缺点：

消息总线本身比较复杂
调试和问题定位复杂
性能开销大
如何保证消息传递的一致性和可靠性

正交架构风格

正交软件架构(Orthogonal Software Architecture) 由组织层(Layer)和线索(Thread)的组件(Component)构成。
其基本思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索(子系统)，线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的组件构成。
特点：

由完成不同功能的n(n>1)个线索(子系统)组成；
系统具有m(m >1)个不同抽象级别的层；
线索之间是相互独立的(正交的)；
系统有一个公共驱动层(一般为最高层)和公共数据结构(一般为最低层)。

优点：

结构清晰，易于理解。
易修改，可维护性强。
可移植性强，重用粒度大。

缺点：

在实际应用中，并不是所有软件系统都能完全正交化，或者有时完全正交化的成本太高。因此，在进行应用项目的软件架构设计时，必须反复权衡进一步正交化的额外开销与所得到的更好的性能之间的关系。

异构风格

异构架构是几种风格的组合。
优点：

选择异构架构风格，可以实现遗留代码的重用。
在某一单位中，规定了共享软件包和某些标准，但仍会存在解释和表示习惯上的不同。选择异构架构风格，可以解决这一问题。

缺点：

不同风格之间的兼容问题有时很难解决