DDD领域驱动设计

1 DDD领域驱动设计是什么

DDD是领域驱动设计，是Eric Evans于2003年提出的，离现在有17年。

2 为什么需要DDD

当软件越来越复杂，实际开发中，大量的业务逻辑堆积在一个巨型类中的例子屡见不鲜，代码的复用性和扩展性无法得到保证。为了解决这样的问题，DDD提出了清晰的分层架构和领域对象的概念，让面向对象的分析和设计进入了一个新的阶段，对企业级软件开发起到了巨大的推动作用。

POP，OOP，DDD是如何解决问题

面向过程编程（POP），接触到需求第一步考虑把需求自顶向下分解成一个一个函数。并且在这个过程中考虑分层，模块化等具体的组织方式，从而分解软件的复杂度。当软件的复杂度不是很大，POP也能得到很好的效果。

面向对象编程（OOP），接触到需求第一步考虑把需求分解成一个一个对象，然后每个对象添加一个一个方法和属性，程序通过各种对象之间的调用以及协作，从而实现计算机软件的功能。跟很多工程方法一样，OOP的初衷就是一种处理软件复杂度的设计方法。

领域驱动设计（DDD），接触到需求第一步考虑把需求分解成一个一个问题域，然后再把每个问题域分解成一个一个对象，程序通过各种问题域之间的调用以及协作，从而实现计算机软件的功能。DDD是解决复杂中大型软件的一套行之有效方式，现已成为主流。

3.DDD模型结构

用户界面/展现层（User Interface）

用户界面层负责向用户显示信息和解释用户指令。

应用层（Application）

应用层定义了软件要完成的任务，并且指挥表达领域概念的对象来解决问题。

领域层（Domain）

负责表达业务概念，业务状态信息以及业务规则，领域模型处于这一层，是业务软件的核心。

基础设施层（Infrastructure）

本层为其他层提供通用的技术能力。

DDD模型结构，从controller（接口层）到service（服务层，业务代码主要实现地）,再到respositiry（根据业务抽象出一些可以复用的方法），最后到mapper（持久层，与数据库交互）。

4.domain 领域模型

domain 领域模型（领域实体），一般项目中会划分多个领域，也会有多个领域实体

domain （领域模型/实体中一般分为：贫血模型，充血模型，失血模型，一般失血模型较为少用）

失血模型：基于数据库的领域设计方式其实就是典型的失血模型，以 Java 为例，POJO 只有简单的基于 field（字段/属性） 的 setter、getter 方法，POJO 之间的关系隐藏在对象的某些 ID 里，由外面的 manager 解释，比如 student.teacherId，学生（student） 并不知道他跟老师（teacher）有关系，但 manager 会通过 student.teacherId 得到一个 Teacher对象，有点类似于父子类中的多肽

贫血模型：和失血模型类似，但更为丰富一些，会被各种service调用，例如学生选课，借书，（student）类会分在不同的业务中，所以一般（student）实体类下会嵌套其他对象属性，通过类的getter方法可以得到一个借书类(Borrowbooks),同理借书类，也可以根据特定方法获取学生类以及其他类

充血模型：充血模型的存在让对象失去了血统的纯正性，他不再是一个纯的内存对象，这个对象里除了有贫血模型的一些方法属性外，还埋藏了一个对数据库的操作，一些业务操作，为保证模型的完整性，充血模型在有些情况下是必然存在的，比如在一个学习里可以有好几千个学生，每个学生有好几百门课程。如果我在构建一个学校的时候把所有学生或者课程都拿出来，这个效率就太差了：

参考文章：

https://blog.csdn.net/WuLex/article/details/123318895

https://blog.csdn.net/qq_43652793/article/details/123864298