1.分层架构有哪些？

单层架构

早期批处理系统，所有的东西都在一个电脑上

两层架构

C/S 架构与P2P 架构
image.png

C/S 应用程序 一部分是由 以与客户端或用户交互为基础的主机，另一部分主机则是专门用于管理大型数据存储库，处理应用特有的数据和逻辑的服务器。

P2P架构不设立服务端，只有客户端。这种架构对于一些去中心化的即时通信应用是有吸引力的。P2P 很适用于语音或视频会议的场景。P2P 的很明显的特征是功能的对称性。

三层架构

在提出该分层架构的时代，多数企业系统往往较为简单，本质上都是一个单体架构（Monolithic Architecture）的数据库管理系统。这种分层架构已经是 Client-Server 架构的进化了，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化
image.png

领域驱动设计相关架构

领域驱动设计的传统分层架构

image.png

层次 职责
用户界面/展现层 负责向用户展现信息以及解释用户命令
应用层  很薄的一层，用来协调应用的活动，它不包含业务逻辑，它不保留业务对象的状态，但它保有应用任务的进度状态
领域层  本层包含关于领域的信息，这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层
基础设施层  本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用

整洁架构

在架构设计时，我们应设计出干净的应用层和领域层，保持它们对业务逻辑的专注，而不掺杂任何具体的技术实现，从而完成领域与技术之间的完全隔离，这一思想被 Robert Martin 称之为整洁架构（Clean Architecture）

image.png
该架构思想提出的模型并非传统的分层架构，而是类似于一个内核模式的内外层架构，由内及外分为四层，包含的内容分别为：

  • 企业业务规则（Enterprise Business Rules）
  • 应用业务规则（Application Business Rules）
  • 接口适配器（Interface Adapters）
  • 框架与驱动器（Frameworks & Drivers）

“企业业务规则”与“应用业务规则”的区别，前者是纯粹领域逻辑的业务规则，后者则面向应用，需要串接支持领域逻辑正常流转的非业务功能，通常为一些横切关注点，如日志、安全、事务等，从而保证实现整个应用流程（对应一个完整的用例）。

六边形架构（端口-适配器模式（port-adapter pattern））

整洁架构的目的在于识别整个架构不同视角以及不同抽象层次的关注点，并为这些关注点划分不同层次的边界，从而使得整个架构变得更加清晰，减少不必要的耦合。它采用了内外层的架构模型弥补了分层架构无法体现领域核心位置的缺陷。由 Alistair Cockburn 提出的六边形架构（Hexagonal Architecture）在满足整洁架构思想的同时，更关注于内层与外层以及与外部资源之间通信的本质：
image.png

优化后的DDD四层架构（依赖倒置原则）

image.png

CQRS架构

CQRS 是“命令查询责任分离”（Command Query Responsibility Segregation）的缩写。在基于 CQRS 的系统中，命令(写操作)和查询(读操作)所使用的数据模型是有区别的。命令模型用于有效地执行写/更新操作，而查询模型用于有效地支持各种读模式。通过领域事件或其他各种机制将命令模型中的变更传播到查询模型中，让两个模型之间的数据保持同步。

image.png

事件总线架构(事件驱动架构（Event-Driven Architecture，EDA）)

事件驱动架构（Event-Driven Architecture，EDA）是一种用于处理事件的生成、发现和处理等任务的软件架构。[Wikipedia，EDA]

image.png

COLA

image.png
1）适配层（Adapter Layer）：负责对前端展示（web，wireless，wap）的路由和适配，对于传统B/S系统而言，adapter就相当于MVC中的controller；

2）应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；

3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；

4）基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。
[

](https://blog.csdn.net/significantfrank/article/details/110934799)
image.png
各个包结构的简要功能描述，如下表所示：

image.png

2.架构为什么要这么演变？

演变思路

单层到两层 ： 单台机器到多台机器
两层到三层： 多台机器到大量机器
三层到领域驱动设计架构： 业务越来越复杂，单系统特别庞大，维护困难

领域驱动设计在经典三层架构的基础上做了进一步改良，在用户界面层与业务逻辑层之间引入了新的一层，即应用层（Application Layer）。同时，一些层次的命名也发生了变化，将业务逻辑层更名为领域层自然是题中应有之义，而将数据访问层更名为基础设施层（Infrastructure Layer），则突破了之前数据库管理系统的限制，扩大了这个负责封装技术复杂度的基础层次的内涵。

Robert Martin 整洁架构的思路是：设计出干净的应用层和领域层，保持它们对业务逻辑的专注，而不掺杂任何具体的技术实现，从而完成领域与技术之间的完全隔离

由 Alistair Cockburn 提出的六边形架构（Hexagonal Architecture）在满足整洁架构思想的同时，更关注于内层与外层以及与外部资源之间通信的本质

根据“依赖倒置原则”与 Robert Martin 提出的“整洁架构”思想，推翻了 Eric Evans 在《领域驱动设计》书中提出的分层架构。Vaughn Vernon 在《实现领域驱动设计》一书中给出了改良版的分层架构，将基础设施层奇怪地放在了整个架构的最上面，整个架构模型清晰地表达了领域层别无依赖的特质

CRRQ：查询和命令分离
一个方法要么是执行某种动作的命令，要么是返回数据的查询，而不能两者皆是。换句话说，问题不应该对答案进行修改。更正式的解释是，一个方法只有在具有参考透明性（referentially transparent）时才能返回数据，此时该方法不会产生副作用。[Wikipedia，CQS]

事件总线：设计初衷是解耦系统模块间相互依赖，解耦事件发送者和事件消接收者，跨系统间的事件监听、订阅、消费。

COLA架构：核心职责就是定义良好的应用结构，提供最佳实践。
从繁杂的业务系统中提炼出共性，找到解决业务问题的最佳共同模式，为开发人员提供统一的认知，治理混乱。帮助应用系统“从混乱到有序”

演变分层的依据与原则

机器为本，用户至上，基于关注点为不同的调用目的划分层次
机器是运行系统的基础，而我们打造的系统却是为用户提供服务的。分层架构中的层次越往上，其抽象层次就越面向业务、面向用户；分层架构中的层次越往下，其抽象层次就变得越通用、面向设备
例如：

  • 三层架构：其上，面向用户的体验与交互；居中，面向应用与业务逻辑；其下，面对各种外部资源与设备
  • 以领域驱动设计的四层架构为例，之所以引入应用层（Application Layer），就是为了给调用者提供完整的业务用例


面对变化，层与层之间的关系应该是正交的
分层时应针对不同的变化原因确定层次的边界，严禁层次之间互相干扰，或者至少把变化对各层带来的影响降到最低
例如：

  • 数据库结构的修改自然会影响到基础设施层的数据模型以及领域层的领域模型，但当我们仅需要修改基础设施层中数据库访问的实现逻辑时，就不应该影响到领域层了

抽象不应该依赖于细节，细节应该依赖于抽象

3.总结：探讨我们项目中应该用哪个？

1.依据项目实际情况考虑

2.吸收其他架构的思想：
整洁架构提出的： 关注核心的逻辑，分离外部依赖，层之间的调用层次分明
CQRS：命令和查询分类 ，重要的业务单独采取一个命令
事件总线架构的 事件驱动思想【解耦较好】

参考链接