ddd思想
设计重点变成了领域，从原来的表的思想性上提高到对象（领域对象上–领域）
业务-功能-设计（功能模型-数据模型）
业务-功能/领域-设计（领域模型）-数据模型
它有三个关键词:领域,驱动,设计
它想解决什么问题：
1.提高了认知维度，以前我们只有三层或者是五层，加上某个表或某几个表，提高到 领域的概念上来。让我们有更多的思想工具去实现业务。
2.规定了业务的边界，在微服务中靠工程定义大的业务边界，在工程内部也有业务边界的定义–领域
3.待发现…
带来的问题：
1.代码的模型会很多– 充写-转换问题
名词解释
cqrs：可以理解为增删改查，对应为XXXquery XXXCmd，–APP层 后缀QryExe或CmdExe
–引用
CQRS模式通过使用不同的接口来分离读取数据和更新数据的操作。CQRS模式可以最大化性能，扩展性以及安全性，
还会为系统的持续演化提供更多的弹性，防止Update命令在域模型Level发生冲突。
CQRS 在 DDD 中是一种常常被提及的模式，它的用途在于将领域模型与查询功能进行分离，让一些复杂的查询摆脱领域模型的限制，以更为简单的 DTO 形式展现查询结果。同时分离了不同的数据存储结构，让开发者按照查询的功能与要求更加自由的选择数据存储引擎。
单一职责，读写分离。
洋葱理论：即为对象的不断分解 不断重构 不断喜欢的过程
领域模型：含有复杂行为的领域或对象
值对象：值对象没有主键属性，或者说，在某个领域下的值对象可以是另一个领域的entity对象，只是再当前领域下，它是一个值而已
聚合 （Aggregate）：是一组生命周期一致的实体集合，表达统一的业务意义。
聚合的意义在于让业务统一、一致，在面向对象中有非常重要价值。
聚合根（ Aggregate Root）：是聚合中最核心的对象，是聚合的领航员
。要管理聚合必须使用一个聚合根，然后使用聚合根来实现发现、持久化聚合的作用。聚合中有且只有一个聚合根，一个实体可以独立作为一个聚合。
（聚合和聚合根不一定要在包名或类名上体现，但重要的是【业务统一、一致】入口统一，收口）
状态机：事件+条件+处理。实现方式：内部其实就是将事件和条件作为key 处理类为value。筛选到就执行。
行为：更多的是对于整体的描述
事件：event，单个点而已，只是一个触发符号
工程结构：不一定完善，待补充
v2：
思考（不一定对，供大家批判）：
不是所有的表都是一个entity，有的只需要cqrs，就不需要存在于domain层，有的只是一个valueobject
ddd再结构上的变更，相当于主体中心从service 转移到了 entity上
虽然现在有一些model+service的嫌疑，但是充血模型下 就很像。另一种思路就是domain层全部为非spring管理类，全程返回app层由app层执行后续操作，但这样会使得app层非厚重
注意：DDD不是想出来的，而是一次次需求迭代出来的。
推荐链接：
一文带你学习DDD，基础入门篇_楼仔的博客-CSDN博客_ddd教程