ddd简单认知（供大家参考批判，欢迎留言）

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教程

COLA 4.0：应用架构的最佳实践_张建飞（Frank）的博客-CSDN博客_cola4.0

DDD—分层架构、洋葱架构、六边形架构 - 走看看