现代系统设计风格概览

将应用程序分成多个层次，每一层都有自己的职责和特殊的关注点，这些层次按照一定规则组织起来，形成一个类似于洋葱的结构，每个层次都只能依赖于它内部的层次，而不依赖于外部的层次，实现了高内聚、低耦合的设计目标。

场景：通用

Java EE应用经常采用的标准模式，将软件按照逻辑层次划分，通常分为业务层、数据层等。 每层都着特定的角色和职能，只能与位于下方的层发生耦合；

场景：通用，适合传统的IT通信和组织结构

CQRS是一种读写分离的架构设计，系统分为两个部分：命令端和查询端，命令端负责处理写操作，而查询端负责处理读操作。在CQRS架构中，写操作和读操作被分离并分布在两个独立的系统中。 实现读写工作负载的独立扩展和优化。

场景： 数据模型不能有效地满足系统的读和写模式； 读操作的请求时远大于写操作

使用附加存储来记录或描述域中数据所采取的动作，从而记录完整的一系列系列事件，而不是仅存储实体的当前状态； 解耦了其生产者（产生事件的任务）和消费者（生成Materialized视图的任务等），为系统的提供了更好灵活性和可扩展性。

场景： Event-Sourcing通常都是配合CQRS模式来执行数据管理任务的。 当开发者希望捕获数据中的“意图”、“目的”或“原因”时； 当开发者希望记录发生的事件，并能够重放它们以恢复系统的状态； 当开发者需要将输入或更新数据的过程与应用这些操作所需的任务解耦时；

一种将实时数据处理和批处理结合起来的架构风格。

使用两套大数据处理引擎，如果两套大数据处理引擎的API不同，有任何逻辑上的改动，需要在两边同步更新，维护成本高，后期的迭代时间周期长。

一种实时数据处理的大数据架构风格。

1. 流式重新处理历史数据的吞吐能⼒会低于批处理 2. 由于上游数据原因，仍然存在数据重新处理的需求（选择具有历史数据的消息队列）

向过程的程序 = 算法 + 数据结构； 关心解决问题的步骤。 面向对象的程序 = 对象 + 交互； 关心谁在解决问题。

分而治之 — 将一个大的需求分解为许多类，每个类处理一个独立的模块，便于分工，每个模块便于复用，可扩展性强。 封装变化 — 变化的地方独立封装，避免影响其他模块。 高 内 聚 — 类中各个方法都在完成一项任务(单一职责的类)。 复杂的实现封装在内部，对外提供简单的调用。 低 耦 合 — 类与类的关联性依赖度要低(每个类独立)。 让一个模块的改变，尽少影响其他模块。

将最小功能核心与扩展功能（客户特定部分）分开的架构，核心系统通常提供系统运行所需的最小功能集。核心系统通常被定义为通用业务逻辑，没有针对特殊情况、特殊规则或复杂条件处理的自定义代码。

场景：Studio、IDEA、互联网浏览器

插件模块是独立的模块，包含特定的处理、额外的功能和自定义代码，来向核心系统增强或扩展额外的业务能力。

插件模块和核心系统的连接方式有多种，包括OSGi (open service gateway initiative)、messaging、web service、甚至点对点绑定（对象实例化），也可以自定义。

整体灵活性高、易于部署、可测试性高、性能高、开发容易度低（契约版本、注册机制、插件粒度、连接方式）

面向企业服务的架构，将软件划分为一系列相互独立的服务。设计通常是自上而下的，服务之间松散耦合，ESB集成不同协议的服务，做消息的转化、解释、路由从而联通各个服务，解决企业通信问题，服务松耦合、可扩展。

使用代理作为中间人来协调和管理服务之间的通信。

场景：各种中间件，如Kafka，RabbitMQ

将软件应用设计为一套可以独立部署的小型模块化服务。

对比SOA：服务粒度更小、去中心化、灵活组合、技术异构

微服务思想=SOA+组件化+领域建模

无服务器架构，通过云服务提供商来管理应用程序的基础架构和资源。

也称为云架构模式，来源于分布式共享内存的概念，通过在多个服务器之间均匀分配服务和资源来避免任何单点故障或性能瓶颈，数据一致性、可靠性、可伸缩性

两个主要组件：处理单元（processing unit）和虚拟化中间件（virtualized middleware）。处理单元通常包含应用程序模块、内存中的数据网格和一个可选的异步持久化转移模块；虚拟化中间件组件用于管理和通信

场景：金融交易系统或在线游戏平台

对等网络架构，每个节点都可以充当客户端和服务器。网络节点直接通信而不需要中央服务器

场景：网络文件共享、流媒体协议

六边形架构的核心理念是应用通过端口与外部进行交互。 软件的业务逻辑与外部关注点分开，由端口和适配器驱动，此模式非常适合需要与其软件环境解耦的应用程序，使它们能够适应新环境。

洋葱架构在端口和适配器架构的基础之上增加了一些的应用业务逻辑的内部组织，这些组织基于领域驱动设计的概念划分的。

领域驱动设计架构，关注领域逻辑和复杂性而非使用的技术。

事件驱动架构，通过事件来推动应用程序的执行和交互，是一种流行的分布式异构模式，用于生成高可伸缩的应用程序。它还具有很强的适应性，既可以用于小型应用程序，也可以用于大型复杂应用程序。事件驱动架构由高度解耦的、单一用途的事件处理组件组成，这些组件异步接收和处理事件。

场景：通知服务

发布-订阅架构，促进事件的生产、检测、消费和响应。 这是一种消息传递模式，消息的发送者（称为发布者）不会将消息编程为直接发送到特定的接收者（称为订阅者）。相反，发布的消息被表征为主题，而不知道可能有哪些订阅者（如果有）。

场景：广泛用于异步系统中，以将生成事件的进程与使用事件的进程解耦，从而实现更大的可扩展性和控制。 消息中间件，RabbitMQ

桌面开发中常见的软件架构， Model（模型）：负责业务数据管理和处理，包括增删改查。Model必须提供外部可以操作模型数据的接口，同时在数据发生变化后能够通知外部 View（视图）：用户界面。View需要感知Model的变化，数据变化时，更新用户界面 Controller（控制器）：业务逻辑层。Controller需要感知View的事件，调用Model提供的接口对数据进行操作

MVC模式的衍生，旨在将数据管理、用户界面和控制流分离。

将model和view进行解隅、通过presenter进行通信。view接收用户交互后，将请求传给presenter进行处理，p传给m，m再传回p通知v进行展示

1. 一个ViewModel只对应一个View，反之亦然; 2. 将视图逻辑移到ViewModel中以简化视图; 3. 视图中使用的数据和ViewModel中的数据之间的一对一映射; 4. 将ViewModel中的数据绑定到View中的数据，这样当ViewModel中的数据发生变化时，它就会立即反映到View中

解释器架构，用于解释和执行特定语言或指令。

场景：SQL 等数据库查询语言、编译器、解析器、正则表达式引擎

采用中央协调器（通常称为编排器）来指导服务之间的交互，负责管理服务之间的控制流和数据流。

该模式实现了一个服务系统，其中每个服务独立工作并通过事件与其他服务交互。没有中央协调器。

该体系结构适合写入繁重的系统

该模式由两种类型的组件组成：主组件和从组件。主组件将工作分配给相同的辅助从组件，并根据这些辅助机器返回的结果计算最终结果。这种模式用于并行计算，通过将巨大的计算任务分配给多个处理器来更快地执行计算。

将数据处理过程划分为一系列阶段，每个阶段都是一种过滤器，数据依次通过这些过滤器。 涉及一系列处理元素（进程、线程、协程等）。

场景：编译器（读取源程序，进行词法和语法分析，将高级语言代码转换为汇编代码） 预处理->编译(词法-语法-语义)->汇编(机器指令)->链接->执行