一、单层架构

单层架构并不算一个规范的架构定义，只是在早期 MVC 三层架构（模型、试图、控制器）还没有那么普及，以及国内开发的项目程序还没有那么规范的时候，用于快速搭建简单网页功能的一种设计。

所有的分层结构的设计，都是以承接功能实现诉求为目的，这一阶段仅仅是完成网页的数据展示，也几乎没有用户交互。所以，很多时候是有多少个页面，就有多少个 Controller 提供接口，以及编写好调用数据库查询数据的操作。

二、三层架构

1978年，MVC模式最早由 Trygve Reenskaug (opens new window)提出，MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式透过对复杂度的简化，使程序结构更加直观。

当 Controller 里承载业务功能逐步变多以后，我们开始思考怎么把这些东西分区存放。那么可以把各类对象归类到一个文件夹，之后把 Controller 里的复杂逻辑拆分为一个个原子的 service 服务，让 Controller 的接口负责调用。 目前的分层架构，就可以适合开发一些复杂逻辑的场景诉求了，不过整体系统的承载量仍然是偏弱一些的。

三、三层架构（分布式）

3层架构出现的很早，其实本身的设计没有考虑复杂的分布式场景。在从三层架构演变到可以支持分布式架构的时候，是没有一个统一的标准规范的，更多的各个公司里自己直接从旧工程里添加了新的 module 分层模块。

首先，一个分布式架构要，对接 rpc、提供 rpc、消费 mq、生产 mq，还要做定时任务（最终一致性补偿），单一个 rpc 的使用，就需要在程序定义出一个 export 层，要打包对外的服务接口，让使用方式引入使用。

之后，原本的 MVC 三层结构就不够用了。只要添加上，export、rpc 这样的分层，原本 service 直接处理数据库的操作，也要考虑拆分出来。

四、四层架构

DDD 是思想，六边形/菱形/整洁架构是分层，DDD 通过建模思想，指导从用例图（use case diagram）出发，与产品、研发、测试一起在一个规范下，脑暴建模。在这个过程中，以结果为导向，分析出可能存在的领域服务。这些领域服务，如登录完成，下单完成，支付完成，收货完成，根据结果态，分析支撑这样的服务所需的对象（实体）、流程、规则等。这样我们可以更加清晰的构建一套系统。

而，六边形（常用的）架构，则是用于承接 DDD 领域驱动设计对系统分析后的编码实现。六边形可以说是专门为 DDD 做的配套架构，虽然也可以用 MVC 来编写，但这样是会失去面向对象设计和编码的优势，让代码逻辑混乱在一起。

首先，六边形架构，以 DDD 领域驱动实际为指引，为 domai 层，设计充血模型结构，如；登录、下单、支付，在每个模块下，包含完整的服务、模型、适配。适配的目的是这个领域里所需的数据，都通过适配的方式从外部调用进来，比如；数据库、缓存、接口等。这是一种 ACL 防腐设计，将来外部的接口变化了，也不会影响领域服务，只要按照领域服务的适配标准提供即可。

之后，围绕着领域 domain 开始，需要啥就让外部的基础设施层实现领域层的接口来提供。而接口要提供啥能力，就调用 case 编排 domain 层，或则简单的由 domain 层直接提供也可以。

最后，也就是 trigger 触发器，我们把接口、任务、mq等都理解为一种触发，之后让 trigger 调用 case 层。case 或者 domain 的目的，就是分摊 trigger 以前 Controller 编写逻辑代码的压力。让 trigger 只是负责对外逻辑的封装，错误码，异常即可。