DDD 领域驱动设计的基本概念 个人理解

新来个技术总监，把DDD落地的那叫一个高级，服气 - 简书 (jianshu.com)

领域驱动设计：从理论到实践，一文带你掌握DDD！ (qq.com)

领域驱动设计在互联网业务开发中的实践 - 美团技术团队 (meituan.com)

1.初次理解DDD时应该想当初学习MVC架构时一样

2.DDD更偏向软技术，和MVC相比对业务的理解、画图、建模模型的能力更高，对个人的要求更高

3.DDD里的很多重要概念必须要先理解，这些是业务层上的，根据这些对业务层进行建模：

 这里面的新词都是需要理解意义，而最需要先理解的就是领域这一层。

4. 代码架构上，分了4层，但是是松散的机构。和MVC对比更好理解。

像是springMVC的映射层、MQ之类的还是最上层的用户接口层、第三方的接口属于获取数据又不影响本领域实体的状态所以属于基础层等等。

 5.具体代码结构上和MVC有很大不同。

 6. 和ai的问答得到的信息。

1). 业务建模和代码结构应对应，调整时应同步进行

2). 实体之间的关系可由UML图等建模图形去处理更好，图形划分领域和资源之间的关系。

3). 实体的划分，聚合、聚合根、上下文界限的划分来确定代码上划分实体等，通过事件风暴推断出可能存在的领域模型和聚合之间的联系等。

d4). 确定领域模型，根据实体创建PO，根据聚合根创建事件类，根据聚合创建领域服务service；领域服务用DO表示，可当做实体去使用；

5). 单一实体代码逻辑可由简单的实体内部、事件监听机制完成。聚合内的通过领域服务去处理，根据是否变实体的状态可进一步划分为查询类、增删改的事件领域服务，业务复杂可以再进一步用策略设计模式去创建更多不同的领域服务类。

6). 简单的实体逻辑代码尽量不要放到领域服务里（比如校验自己的属性），建议抽取到放到实体内部方法上。

7). 在访问mapper或者缓存前，由Repository去处理具体的持久化方案，

8.) 对象之间形态的转换统一由 Assembler 处理，创建对象建议Factory等。

9).