学习DDD总结

为什么80%的码农都做不了架构师？>>>   

实体

实体是业务系统中分析得出的业务对象，诸如用户、产品之类的，它们需持久于数据层，有自己的属性。

但实体并不是数据展现层所需的数据载体，它只是一种业务载体。它定义的关于本实体的业务方法，并将这些业务方法所对本实体的改变持久化到数据层。

实体不提供直接修改其内部业务属性的方法，也就是说，不再有setter方法。改变内部业务属性只能是有能表达业务、并能通用语言表达的方法来处理。

实体不提供直接读取其内部业务属性的方法，它是通过值对象对外发布其业务属性（或限制访问）。

值对象

是一种承载数据的不可变的对象。

一般可以这么理解，它只是用来传输数据的，它与具体的业务模型无关。一般情况下它是实体的数据展现形式，因为实体只是业务载体，并不存在展示数据的能力，所以实体要想给展示层显示数据，那么就要转换成一个值对象，让展示层渲染值对象即可，同样，这也解决了如何不使用osiv的问题。

领域服务

有一些业务操作在不好归结为实体方法的时候，那么它就极有可能是领域服务。

又或者有一大流程的、大量业务规则的、并且不好归结为实体方法的时候，那么它一定是领域服务。

领域服务有以下几个特征：

1. 调用多个实体协同完成一个复杂的逻辑业务流程。
2. 实体转换值对象。
3. 返回值为值对象。

过份强调领域服务会导致贫血模型，那么什么时候才是使用实体方法，什么时候才是使领域服务呢？

1. 因为实体业务属性是不能被外界直接访问的，所以，当你要访问这些业务属性才能完成业务功能的时候，那么就要实现成实体方法，而不是领域服务。
2. 当一个业务操作是由多个不同的实体协作，并且业务流相当复杂的时候，比方说吧，如果非得由实体方法实现，但是调用方需要调用多个实体方法才能完成这个业务操作的话，那么这个业务操作需要实现成领域服务的一个业务方法。
3. 如果混有以上两点的，那么肯定是要实现成领域服务，只是实体方法的工作范围会缩窄。

领域事件

经典的观察者模式，但是在这里却是相当有用的。主要体现在以下几个方面：

1. 更加关注业务本身，而由业务本身所影响产生的附加业务则可以实现为更为专注的业务单元。
2. 业务与附属操作解偶，系统更易于扩展。
3. 更容易与其它子系统集成。

领域事件给开发大型的、复杂的系统提供了细化业务的可能。

转载于:https://my.oschina.net/kut/blog/407161