「DDD」的全称是「Domain-driven Design」，即「领域驱动设计」。是由「Eric Evans」最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。
DDD是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。
其实简单来说：就是为了解决业务的复杂性
修改一个功能时，回溯该功能需要的修改点需要一定的时间。service层随着业务的复杂而变得臃肿。重构提炼出来的设计模型，并不具有实际的业务含义所以我们尝试用领域驱动而非传统的数据驱动的的思维模式去实现我们业务功能。在代码实现上用四层架构而非传统的三层架构。领域层专注于业务，基础设施层专注于技术，使业务与技术实现解耦分离，极大的提高了代码的可维护性领域驱动说白了就是进行业务建模，对业务进行抽象形成领域层，也就是业务模型层。业务相关的操作封装进领域层中，通过仓储将领域层与传统的dao层进行解耦。
DDD如何落地DDD开发流程图
相关概念如下
实体：具有唯⼀标识，包含着业务知识的充⾎模型对象，⽤于对唯进⾏建模
值对象：生成后即不可变对象，通常作为实体的属性，⽤于描述领域中的事物的某种特征
聚合：聚合是业务和逻辑紧密关联的实体和值对象组合而成
聚合根: 聚合根是实体，具备唯一标识，有独立的生命周期，一个聚合只有一个聚合根
领域服务: 分担实体的功能，承接部分业务逻辑，做⼀些实体不便处理的业务流程。不是必须的。
资源库: 保存聚合的地⽅，将聚合实例存放在资源库（Repository）中，之后再通过该资源库来获取相同的实例
具体组合关系如下：
4.DDD实战-分析过程
代码编排：
业务分析过程
1.业务场景分析
根据业务流程或用户旅程，采用用例和场景分析，找出事件、命令
2.设计领域服务
如果一个核心业务动作或行为跨多个实体，我们就需要设计领域服务
3.设计实体、值对象、聚合根
第一步：从命令和事件中提取产生这些行为的实体或者值对象。
第二步：对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根
4.设计仓储
每一个聚合都有一个仓储，仓储主要用来完成数据查询和持久化操作。仓储包括仓储的接口和仓储实现，实现应用业务逻辑与数据库资源逻辑的解耦
