我理解的DDD
参考资料
阿里的五篇DDD分享：
kratos v2的DDD实践：
https://go-kratos.dev/blog/go-project-layout/
首先是学习DDD要分别学习什么东西
-
六边形架构
-
DDD角度的业务架构图
-
DP
-
DTO
-
DO
-
PO
-
Domain Service
-
防腐层
-
Repository
-
use case
-
Entity ，
-
Assembler
-
Converter
-
Value Object
-
Command、Query、Event对象
- 聚合根
- 上下文界限
下面逐步解释：
首先从高层角度来说
就是学习 六边形架构 （参见 阿里技术专家详解DDD系列 第二讲 - 应用架构 - 知乎）
就是
核心是domain layer，
再外面是Application layer，
再外面是Infrastructure Layer
按照理论内部业务可以快速迭代，反而是外部Infrastructure Layer是稳定的
这就打破了之前架构设计的上下分层的结构
然后就是各种小概念
|
DP 跳过，先忽略
|
|
DTO，data transfer object
就是http grpc的resp就是DTO
|
|
DO，domain object
就是数据表的直观映射，
每个属性对应数据表的一个列
|
|
Entity，实体
就是具体的业务逻辑类
|
|
PO
好像也是持久化对象
也是数据表的直观映射
先忽略这个东西，跳过
|
|
Repository
就是对db操作的抽象接口
不依赖db层具体的实现
就是一个接口，不是一个类
接口中的各个方法都是对业务的操作，而且是save 、find
这种按业务语义来命名的方法，不是create，update这种按db操作命名的方法
|
|
Repository实现类
具体负责操作db，sql操作写在这里
|
|
防腐层Anti-Corruption Layer，ACL
和Repository 类似的，就是对调用外部的抽象接口
也是不依赖具体的实现，而是依赖接口
|
|
防腐层ACL实现类
具体调外部接口，将外部接口返回值，转为一个我们自己定义的DTO来自己内部使用
然后返回给调用者
DTO这里注意，
不仅仅是我们服务的resp是DTO
外部服务的resp，我们也做一层转化，转为DTO
（领域层内使用DTO吗，不用entiyi吗）
|
|
use case
就是一个use case类，类下面的各个方法都是具体的业务方法，完成业务逻辑
这么算来use case类型也在领域层
|
|
Assembler
就是指Entity到DTO的转化器
有一个类专门的类来做个转化
同时注意一般没有DTO到Entity的转化器，一般不需要这么转化
|
|
Converter
就有个类专门复制转化
就是Entity到DO的转化器，也是DO到Entity的转化器
|
|
Value Object
先忽略
|
|
Command、Query、Event对象
具体解释在这里
就是app service的传参
就是领域层接收的参数
|
|
聚合根
TODO
|
|
上下文界限
TODO
|
画图理解：
DTO，entity，DO的转化的图：
DDD角度的业务架构图：
代码理解：
我的kratos helloworld github代码：https://github.com/androo789/kratos_v2_helloworld
没有完全按照理论
没有完全按照理论
注意具体实践过程中还有所取舍
DDD优点缺点
1
结构清晰
实践软件设计原则
单一原则
依赖倒置原则
（话说其实不用DDD，也可以这么实践）
2
缺点是带来了大量的代码膨胀
引入了一些复杂性
比如聚合根的repo操作，可能有些entity不修改，有些entity修改
我知道这个写的很粗糙🤔
但是现有个大概的框架
细节再补充
一次理解不到位
多理解几次
