摘要
1）DDD的战略设计其实是架构设计，战术设计则相当于编码实现(技术实现）
2）应用服务相当于是系统的门面，在DDD中是必须存在的，遵循的原则有：
- 一个业务用例对应与应用服务的业务方法
- 本身不应该包含业务逻辑：业务逻辑应该放在领域模型中实现，更准确的说是放在聚合根中实现
- 与UI或通信协议无关：ApplicationService的定位并不是整个软件系统的门面，而是领域模型的门面，这意味着ApplicationService不应该处理诸如UI交互或者通信协议之类的技术细节
- 接受原始数据类型：ApplicationService作为领域模型的调用方，领域模型的实现细节对其来说应该是个黑盒子，因此ApplicationService不应该引用领域模型中的对象
3）实体对象表示的是具有一定生命周期并且拥有全局唯一标识(ID)的对象
4）值对象：推崇将业务概念尽量建模为值对象
5）DomainService：聚合根是业务逻辑的主要载体，也就是说业务逻辑的实现代码应该尽量地放在聚合根或者聚合根的边界之内。但有时，有些业务逻辑并不适合于放在聚合根上，比如涉及到外部数据交换，中间临时数据获取(依赖远程服务），协调多个聚合根(实体)来完成一段逻辑。DomainService是一种妥协的结果，程序中尽量少使用，增加了理解复杂度。
6）Command：通过查看Command就能知道系统对外提供的业务功能
7) Repository: 一个聚合根(实体)的资源库
8) 实体一般对应业务对象，具有业务属性和业务行为
9) 值对象主要是属性集合，描述实体的状态和特征, 实体某个时刻的状态值
10) 在DDD中有一条原则：一个业务用例对应一个事务，一个事务对应一个聚合根，也即在一次事务中，只能对一个聚合根进行操作. 跨多个聚合根或事物可考虑使用领域事件或DomainService。
小结
基于DDD的开发，针对软件中的写场景，主要有3种：
- 通过聚合根完成业务请求
- 通过Factory完成聚合根的创建
- 通过DomainService完成业务请求
以上3种场景大致上涵盖了DDD完成业务写操作的基本方面，总结下来3句话：创建聚合根通过Factory完成；业务逻辑优先在聚合根边界内完成；聚合根中不合适放置的业务逻辑才考虑放到DomainService中。
而DDD中的读操作可以大致分为3种实现方式
参考资料
若有收获，就点个赞吧
0 人点赞
