领域驱动设计实现之路

　　聚合（Aggregate）

　　聚合可能是DDD中最难明白的观点 ，之以是称之为聚合，是由于聚合中所包罗的工具之间具有密不行分的联系，他们是内聚在一起的。好比一辆汽车（Car）包罗了引擎（Engine）、车轮（Wheel）和油箱（Tank）等组件，缺一不行。一个聚合中可以包罗多个实体和值工具，因此聚合也被称为根实体。聚合是持久化的基本单元，它和资源库（请参考下文）具有逐一对应的关系。

　　既然聚合可以容纳其他领域工具，那么聚合应该设计得多大呢？这也是设计聚合的难点之一。好比在一个博客（Blog）系统中，一个用户（User）可以建立多个Blog，而一个Blog又可以包罗多篇博文（Post）。在建模时，我们通常的做法是在User工具中包罗一个Blog的荟萃，然后在每个Blog中又包罗了一个Post的荟萃。你真的需要这么做吗？若是你需要修改User的基本信息，在加载User时，所有的Blog和Post也需要加载，这将造成很大的性能消耗。诚然，我们可以通过延迟加载的方式解决问题，可是延迟加载只是手艺上的实现方式而已。导致上述问题的深层缘故原由实在在我们的设计上，我们发现，User更多的是和认证授权相关的观点，而与Blog关系并不大，因此完全没有须要在User中维护Blog的荟萃。在将User和Blog分散之后，Blog也和User一样成为了一个聚合，它拥有自己的资源库。问题又来了：既然User和Blog分散了，那么若是需要在Blog中引用User又该怎么办呢？在一个聚合中直接引用另外一个聚合并不是DDD所勉励的，可是我们可以通过ID的方式引用另外的聚合，好比在Blog中可以维护一个userId的沈阳软件制作实例变量。

　　User作为Blog的建立者，可以成为Blog的工厂。放到DDD中，建立Blog的功效也只能由User完成。

　　综上，对于“建立Blog”的用例，我们可以通过以下要领完成：

public class Customer {    private String email;    public void setEmail(String email) {        this.email = email;    }} 

　　在上例中，营业用例通过BlogApplicationService应用服务完成，在用例要领createBlog()中，首先通过User的资源库获得一个User，然后挪用User中的工厂要领createBlog()要领建立一个Blog，最后通过BlogRepository对Blog举行持久化。整个历程组成了一次事务，因此createBlog()要领标志有@Transactional作为事务界限。

　　使用聚合的主要原则为在一次事务中，最多只能更改一个聚合的状态。若是一次营业操作涉及到了对多个聚合状态的更改，那么应该接纳公布领域事务（参考下文）的方式通知响应的聚合。此时的数据一致性便从事务一致性酿成了最终一致性（Eventual Consistency）。

　　领域服务（Domain Service）

　　你是否遇到过这样的问题：想建模一个领域观点，把它放在实体上不合适，把它放在值工具上也不合适，然后你冥思苦想着自己的建模方式是不是出了问题。恭喜你，祝贺你，你的建模手法完全没有问题，只是你还没有接触到领域服务（Domain Service）这个观点，由于领域服务原来就是来处置惩罚这种场景的。好比，要对密码举行加密，我们便可以建立一个PasswordEncryptService来专门卖力此事。

　　值得一提的是，领域服务和上文中提到的应用服务是差别的，领域服务是领域模子的一部门，而应用服务不是。应用服务是领域服务的客户，它将领域模子酿成对外界可用的软件系统。

　　领域服务不能滥用，由于若是我们将太多的领域逻辑放在领域服务上，实体和值工具上将酿成血虚工具。

　　资源库（Repository）

　　资源库用于生存和获取聚合工具，在这一点上，资源库与DAO几多有些相似之处。可是，资源库和DAO是存在显著区此外。DAO只是对数据库的一层很薄的封装，而资源库则越发具有领域特征。另外，所有的实体都可以有响应的DAO，但并不是所有的实体都有资源库，只有聚合才有响应的资源库。

　　资源库分为两种，一种是基于荟萃的，一种是基于持久化的。顾名思义，基于荟萃的资源库具有编程语言中荟萃的特征。举个例子，Java中的List，我们从一个List中取出一个元素，在对该元素举行修改之后，我们并不用显式地将该元素重新生存到List内里。因此，面向荟萃的资源库并不存在save()要领。好比，对于上文中的User，其资源库可以设计为：

 4/5   首页 上一页 2 3 4 5 下一页 尾页