DDD 架构演进，从单层、三层，四层，工程分层演进过程！

作者：小傅哥
博客：https://bugstack.cn (opens new window)

沉淀、分享、成长，让自己和他人都能有所收获！😄

定义接口、创建方法、调用展示，其实编程写代码说到底也就这3步，人人都是程序员👨🏻‍💻。公司老板都觉得，它有个AI工具，它都能写代码。但现在的系统工程的分层结构，可不只是一层就写个 Controller，甚至是3层（Model-View-Controller），也有可能是4层（DDD）架构。这样的分层架构怎么理解呢？

刚入行，直接就开大吗？

在我最早接触编程的时候，还是9大内置对象，servlet、jsp、前端也是刚接触《锋利的JQuery》的时代。甚至很多流程代码都堆到了 jsp 页面，后端也就是连库做 CRUD 操作。多好的时代，学一点东西，就能上班赚钱了。现在要学的可就多了，仅专业技能部分，都能在写满简历 1/3 篇幅了！

但没办法，人嘛，总是要向钱低头的，向前！毕竟，互联网公司都是飞速迭代发展的，所以，要想混个能在群里喊【收到、收到】的资格，也得加倍学习。

所以，小傅哥就给大家分享下，关于系统分层架构的演进过程，看看这东西是怎么从简简单单变得复复杂杂的。

一、单层架构

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

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

二、三层架构

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

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

三、三层架构（分布式）

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

• 首先，一个分布式架构要，对接 rpc、提供 rpc、消费 mq、生产 mq，还要做定时任务（最终一致性补偿），单一个 rpc 的使用，就需要在程序定义出一个 export 层，要打包对外的服务接口，让使用方式引入使用。关于为什么需要这样的方式，可以在 bugstack.cn (opens new window) 编程路书中，开发技术部分 dubbo 学习。
• 之后，原本的 MVC 三层结构就不够用了。只要添加上，export、rpc 这样的分层，原本 service 直接处理数据库的操作，也要考虑拆分出来。可能这部分每个公司还不一样，其实即使一个公司，不同组，也是有很大的差异。这个也是目前互联网公司中的项目里的一个现状问题。
• 思考，现在的工程模型结构其实很杂，装填了太多的东西进去了。除此之外，因为都是原子化编写，没有在做分区。一个系统里 service 都有上千个类，每个类里又有上千行代码。在坐的各位，应该都会在这些屎山中赚钱。

四、四层架构

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

而，六边形（常用的）架构，则是用于承接 DDD 领域驱动设计对系统分析后的编码实现。六边形可以说是专门为 DDD 做的配套架构，虽然也可以用 MVC 来编写，但这样是会失去面向对象设计和编码的优势，让代码逻辑混乱在一起。所以，这也是各个互联网公司开始往 DDD 架构切换的目的。这件事，我已经干了好几年了！

• 首先，六边形架构，以 DDD 领域驱动实际为指引，为 domai 层，设计充血模型结构，如；登录、下单、支付，在每个模块下，包含完整的服务、模型、适配。适配的目的是这个领域里所需的数据，都通过适配的方式从外部调用进来，比如；数据库、缓存、接口等。这是一种 ACL 防腐设计，将来外部的接口变化了，也不会影响我们的领域服务，只要按照领域服务的适配标准提供即可。
• 之后，围绕着领域 domain 开始，需要啥就让外部的基础设施层实现领域层的接口来提供。而接口要提供啥能力，就调用 case 编排 domain 层，或则简单的由 domain 层直接提供也可以。
• 最后，也就是 trigger 触发器，我们把接口、任务、mq等都理解为一种触发，之后让 trigger 调用 case 层。case 或者 domain 的目的，就是分摊 trigger 以前 Controller 编写逻辑代码的压力。让 trigger 只是负责对外逻辑的封装，错误码，异常即可。

综上，就是关于架构分层的一个演进过程，现在还有 AI 的加入，AI 也会逐步成为整个工程架构中的一块。关于这部分的架构设计，与业务工程的结合，小傅哥也会在 bugstack.cn 博客中陆续更新。