DDD全名，领域驱动设计。是一门软件设计理论，在面向对象的基础上进一步，作用是设计出低耦合、高内聚的软件产品，通过分层的设计思想，是软件达到扩展、性能、易读性；
业务建模和大数据建模的桥梁；
为了devops和低代码生成器的标准化规范前提；
为了清晰业务系统，清晰业务系统模型和后续大数据建模；
devops是根据DDD领域驱动的持续集成、测试、敏捷开发、交付；
-
首先，需要对一个业务需求分析，创建领域模型；
-
然后，将模型对象和业务逻辑，开发落实到四层代码当中的领域层domain；【应用层application、领域层domain、用户界面层interfaces、基础设施层infrastructure】
-
再然后，理解一下概念
-
应用层application：全是接口interface没有接口的实现，和定时任务； -
用户界面层interfaces：全是controllers和dto，也就是说这里controllers是对外提供的restful api,dto则是api带验证的入参对象； -
基础设施层infrastructure：配置文件、工具包、数据库连接、权限、拦截器、过滤器、公共组件、全局变量、全局常量等； -
pom.xml:引入依赖的外部包、外部公共组件； -
业务逻辑、业务过程、业务行为：可以理解业务逻辑是由多个业务行为（也叫业务过程）串联组成； -
领域=聚合=表的全部内容=大圆圈； -
领域对象=小椭圆=表字段=也可以是业务过程； -
聚合根=聚合和聚合之间关联（主键、外键）=表名；
最后，分四层的目的，使得代码清晰，便于迁移。新项目复用的时候，只需要将领域层、应用层的代码拷贝出来，在新项目的用户界面层进行引用即可；多么清晰的代码结构：
如何设计聚合？简单说就是对业务需求的理解，抽离出业务行为，在然后对业务行为抽离出领域对象【大圆圈是聚合，小椭圆是领域对象】
举例：保单系统聚合的过程；
我们收到一个客户需求，首先不是画业务流程图，也不是先搞数据库设计，也不是先画产品原型；我们应该先做DDD领域建模，把客户的需求从语言文字量化到领域对象和业务过程，用图形化归纳起来，形成业务总体设计，一目了然。然后再建立业务流程图，再ER图，再原型，再架构，再开发；
