参考资料
阿里的五篇DDD分享：
https://zhuanlan.zhihu.com/p/340911587 https://zhuanlan.zhihu.com/p/343388831 https://zhuanlan.zhihu.com/p/348706530 https://zhuanlan.zhihu.com/p/356518017 https://zhuanlan.zhihu.com/p/366395817 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对象 具体解释在这里 阿里技术专家详解DDD系列 第五讲：聊聊如何避免写流水账代码 - 知乎 就是app service的传参 就是领域层接收的参数 |
| 聚合根 TODO |
| 上下文界限 TODO |
画图理解： DTO，entity，DO的转化的图：
DDD角度的业务架构图：
代码理解：
TODO：我的kratos helloworld github代码没有完全按照理论 注意具体实践过程中还有所取舍
DDD优点缺点
1 结构清晰 实践软件设计原则 单一原则 依赖倒置原则 （话说其实不用DDD，也可以这么实践） 2 缺点是带来了大量的代码膨胀 引入了一些复杂性 比如聚合根的repo操作，可能有些entity不修改，有些entity修改我知道这个写的很粗糙 标签：DTO,接口,Entity,理解,https,zhihu,DDD From： https://www.cnblogs.com/dong-qi/p/17059436.html