DDD 领域驱动设计－两个实体的碰撞火花

在之前的项目开发中，只有一个 JsPermissionApply 实体（JS 权限申请），所以，CNBlogs.Apply.Domain 设计的有些不全面，或者称之为不完善，因为在一些简单的项目开发中，一般只会存在一个实体，单个实体的设计，我们可能会忽略很多的东西，从而以后会导致一些问题的产生，那如果再增加一个实体，CNBlogs.Apply.Domain 该如何设计呢？

按照实际项目开发需要，CNBlogs.Apply.Domain 需要增加一个 BlogChangeApply 实体（博客地址更改申请）。

在 BlogChangeApply 实体设计之前，我们按照之前 JsPermissionApply 实体设计过程，先大致画一下流程图：

流程图很简单，并且和之前的 JS 权限申请和审核很相似，我们再看一下之前的 JsPermissionApply 实体设计代码：

根据博客地址更改申请和审核的流程图，然后再结合上面 JsPermissionApply 实体代码，我们就可以幻想出 BlogChangeApply 的实体代码，具体是怎样的了，如果你实现一下，会发现和上面的代码简直一摸一样，区别就在于多了一个 TargetBlogApp（目标博客地址），然后后面的 Repository 和 Application.Services 复制粘贴就行了，没有任何的难度，这样设计实现也没什么问题，但是项目中的重复代码简直太多了，领域驱动设计慢慢就变成了一个脚手架，没有任何的一点用处。

该如何解决上面的问题呢？我们需要思考下 CNBlogs.Apply.Domain 所包含的含义，CNBlogs.Apply.Domain 顾名思议是申请领域，并不是 CNBlogs.JsPermissionApply.Domain，也不是 CNBlogs.BlogChangeApply.Domain，实体的产生是根据聚合根的设计，那 CNBlogs.Apply.Domain 的聚合根是什么呢？在之前的设计中只有 IAggregateRoot 和 IEntity，具体代码：

现在再来看上面这种设计，完全是错误的，聚合根接口怎么能继承实体接口呢，还有一个问题，就是如果有多个实体设计，是继承 IAggregateRoot？还是 IEntity？IEntity 在这样的设计中，没有任何的作用，并且闲的很多余，IAggregateRoot 到最后也只是一个抽象的接口，CNBlogs.Apply.Domain 中并没有具体的实现。

解决上面混乱的问题，就是抽离出 ApplyAggregateRoot（申请聚合根），然后 JsPermissionApply 和 BlogChangeApply 实体都是由它进行产生，在这之前，我们先定义一下 IAggregateRoot：

然后根据 JS 权限申请/审核和博客地址更改申请/审核的流程图，抽离出 ApplyAggregateRoot，并且继承自 IAggregateRoot，具体实现代码：

ApplyAggregateRoot 的实现，基本上是抽离出 JsPermissionApply 和 BlogChangeApply 实体产生的重复代码，比如不管什么类型的申请，都包含申请理由、申请人信息、通过或拒绝等操作，这些也就是 ApplyAggregateRoot 所体现的领域含义，我们再来看下 BlogChangeApply 实体的实现代码：

BlogChangeApply 继承自 ApplyAggregateRoot，并且单独的 TargetBlogApp 操作，其他一些实现都是基本的参数传递操作，没有具体实现，JsPermissionApply 的实体代码就不贴了，和 BlogChangeApply 比较类似，只不过有一些不同的业务实现。

CNBlogs.Apply.Domain 改造之后，还要对应改造下 Repository，之前的代码大家可以看下 Github，这边我简单说下改造的过程，首先 IRepository 的设计不变：

IRepository 对应 BaseRepository 实现，它的作用就是抽离出所有聚合根的 Repository 操作，并不单独包含 ApplyAggregateRoot，所以，我们还需要一个对 ApplyAggregateRoot 操作的 Repository 实现，定义如下：

大家如果熟悉之前代码的话，会发现 IApplyRepository 的定义和 IJsPermissionApplyRepository 的定义是一摸一样的，设计 IApplyRepository 的好处就是，对于申请实体的相同操作，我们就不需要再写重复代码了，比如 IJsPermissionApplyRepository 和 IBlogChangeApplyRepository 的定义：

CNBlogs.Apply.Sample 开发进行到这，对于现阶段的我来说，应用领域驱动设计我是比较满意的，虽然还有一些不完善的地方，但至少除了 CNBlogs.Apply.Domain，在其他项目中是看不到业务实现代码的，如果业务需求发生变化，首先更改的是 CNBlogs.Apply.Domain，而不是不是其它项目，这是一个基本点。

先设计 CNBlogs.Apply.Domain 和 CNBlogs.Apply.Domain.Tests，就能完成整个的业务系统设计，其它都是一些技术实现或工作流程实现，这个路子我觉得是正确的，以后边做边完善并学习。

本文转自田园里的蟋蟀博客园博客，原文链接：http://www.cnblogs.com/xishuai/p/ddd-design-two-entities.html，如需转载请自行联系原作者