EntityFramework之领域驱动设计实践(五)

聚合

聚合(Aggregate)是领域驱动设计中非常重要的一个概念。简单地说,聚合是这样一组领域对象(包括实体和值对象),这组领域对象联合起来表述一个完整的领域概念。比如,根据Eric Evans《领域驱动设计》一书中的例子,一辆车包含四个轮子,轮子离开“车”就毫无意义,此时这个联合体就是聚合,而“车”就是聚合根(Aggregate Root)。

从实践中得知,并非领域模型中的每个实体都能够完整地表述一个明确的领域概念,就比如客户与送货地址的关系。假设在某个应用中,系统需要为每个客户维护多个送货地址,此时送货地址就是一个实体,而不是值对象。那么这样一来,领域模型中至少就有了“客户”和“送货地址”两个实体,而事实上,“送货地址”是针对“客户”的,离开“客户”,“送货地址”就变得毫无意义。于是,“送货地址”就和“客户”一起,完整地表达了“客户可以有多个送货地址,并能对它们进行维护”的思想。

《实体框架之领域驱动实践(三) - 案例:一个简易的销售系统》一文中,我们简单地设计了一个领域模型,其中包含了一些必要的实体和值对象。现在,我用不同颜色的笔在这个领域模型上圈出了三个聚合:客户、订单以及产品分类,如下图所示:

 

24150813078

 

 

【注意】:如果像上图所示,Category-Item组成一个聚合,那么此时聚合根就应该是Item,而不是Category,因为Category对Item从概念上并没有包含/被包含的关系,而更多情况下,Category是 Item的一种信息描述,即某个Item是可以归类到某个Category的。在这种情况下,我们不需要对Category进行维护,Category就以值对象的形式存在于领域模型中。如果是另一种应用场合,比如,我们的系统需要针对Category进行促销,那么我们需要维护Category的信息,由此Category和Item就分属两个不同的聚合,聚合根为各自本身。

首先是“客户-信用卡”聚合,这个聚合表示了一个客户可以拥有多张信用卡,类似于上面所讲的 “客户-送货地址”的概念;其次是“订单-订单行”的聚合,类似地,虽然订单行也是一个实体,因为在应用中需要对每个订单行进行区分,但是订单行离开订单就变得毫无意义,它是“订单”概念的一部分;最后是“产品分类-产品”的聚合。

每个聚合都有一个根实体(聚合根,Aggregate Root),这个根实体是聚合所表述的领域概念的主体,外部对象需要访问聚合内的实体时,只能通过聚合根进行访问,而不能直接访问。从技术角度考虑,聚合确定了实体生命周期的关注范围,即当某个实体被创建时,同时需要创建以其为根的整个聚合,而当持久化某个实体时,同样也需要持久化整个聚合。比如,在从外部持久化机制重建“客户”对象的同时,也需要将其所拥有的“信用卡”赋给“客户”实体(具体如何操作,根据需求而定)。不要去关注聚合内实体的生命周期问题,如果你真的这么做了,那么你就需要考虑下你的设计是否合理。

由此引出了“领域对象生命周期”的问题,这个问题我会在后面两节单独讨论,但目前至少知道:

  1. 领域对象从无到有的创建,不是针对某个实体的,而是针对某个聚合的
  2. 领域对象的持久化(通常所说的“保存”)、重建(通常所说的“查询”)和销毁(通常所说的“删除”)也不是针对某个实体的,而是针对某个聚合的

很可惜,微软的EntityFramework(实体框架,EF)目前并不支持“聚合”的概念,所有的实体都被一股脑地塞到 ObjectContext中:

241532814506

为了实现聚合的概念,我们又一次地需要用到“部分类(partial class)”的功能。我们首先定义一个IAggregateRoot的接口,修改每个聚合根的实体类,使其实现IAggregateRoot接口,如下:

隐藏行号 复制代码 IAggregateRoot
  1. public interface IAggregateRoot
    
  2. {
    
  3. }
    
  4. 
    
隐藏行号 复制代码 聚合根
  1. [AggregateRoot("Orders")]
    
  2. partial class Order : IAggregateRoot
    
  3. {
    
  4.     public Single TotalDiscount
    
  5.     {
    
  6.         get
    
  7.         {
    
  8.             return this.Lines.Sum(p => p.Discount);
    
  9.         }
    
  10.     }
    
  11. 
    
  12.     public Single TotalAmount
    
  13.     {
    
  14.         get
    
  15.         {
    
  16.             return this.Lines.Sum(p => p.LineAmount);
    
  17.         }
    
  18.     }
    
  19. 
    
  20. }
    
  21. 
    

到这里又有问题了,接口IAggregateRoot中什么都没有定义?!我在我的技术博客中,特别解释了C#中接口的三种用途,请参考这篇文章:《C#基础:多功能的接口》。在这里,我们将IAggregateRoot接口用作泛型约束。在看完后续的两篇介绍领域对象生命周期的文章后,你就能够更好地理解这个问题了。事实上,在领域驱动设计的社区中,不少人都是这样用的。

最后说明一下,由于实体框架使所有的实体类继承于EntityObject类,而从面向对象的角度,接口是没办法去继承于类的,因此,在这里我们的 IAggregateRoot接口好像跟实体没什么太大的关系,而事实上聚合根应该是一种实体。在很多领域驱动的项目中,设计人员专门设计了 IEntity接口,所有实现了该接口的类都被认定为实体类,于是,IAggregateRoot接口也就很自然地继承IEntity接口,以表示“聚合根是一种实体”的概念,代码大致如下:

隐藏行号 复制代码 IAggregateRoot
  1. public interface IEntity
    
  2. {
    
  3.     Guid Id { get; set; }
    
  4. }
    
  5. public interface IAggregateRoot : IEntity
    
  6. {
    
  7.     
    
  8. }
    
  9. 
    

总的来说,领域模型需要根据领域概念分成多个聚合,每个聚合都有一个实体作为“聚合根”,通俗地说,领域对象从无到有的创建,以及CRUD操作都应该作用在聚合根上,而不是单独的某个实体。当你的代码需要直接对聚合内部的实体进行CRUD操作时,就说明你的模型设计已经存在问题了。

 

 

-----【以下为原文网友评论及回复信息】-----
 

Re:实体框架之领域驱动实践(五)

[ 2010-1-11 9:22:00 | By: ruson(游客) ]

理论上是很好的,但实践中感觉有些局限性。
如上文所说Category和Item是一个聚合,Category是聚合根。那如果一个apsx页中要打开id为1的Item信息,是否还要把 Category的id也传过来。先从数据库中取出Category,再从Category中取Item呢。

以下为blog主人的回复:
你的问题很有价值!
Category可以是聚合根,也可以不是,应该根据实际情况进行考虑。如果我们不需要对Category进行维护,那么将Category和Item划归一个聚合,聚合根应该是Item而不是Category,也就是说,Category应该是Item的一部分,Category作为值对象存在。考虑另外一种应用场合,比如在订单上使用销售折扣,这个折扣可以应用在Item上,也允许应用在Category上(比如某个客户如果买了这个Category 下的Item,那么就按多少的折扣给他),那么此时就不得不去维护Category的信息,于是,Item和Category分属两个不同的聚合,聚合根为其本身。
这里也让我们了解到,实体和值对象没有明确的分界线,只能是设计人员在实践中根据自己的实际经验把握。
【另外,对于文章中给大家造成的不合理引导,我深表歉意,我会在文章中保留原本错误的部分,然后将勘误用橙色笔标注以备参考。也非常欢迎大家能够提出自己的问题与疑惑】

Re:实体框架之领域驱动实践(五)

[ 2010-1-16 9:17:00 | By: ruson(游客) ]

你好,按现实中的常规,应该先有分类才有分类下的子项,Item是属于Category下的一个集合,Category优先于Item而存在。
在Item必需有分类的情况下,Item离开了Category就显得无意义,所以我的想法是Category应该为聚合根。但会遇到上面我所提到的问题。以及如果只想对其中某一个Item进行CURD时还要先取出来整个聚合根的话对性能的影响有些疑问。
谢谢。

以下为blog主人的回复:
你好!这个问题确实让人难以理解,开始的时候,我承认我自己也没有经过深思熟虑就把结论写在这里,造成很多朋友的误解,再次深表歉意。
由于你现在需要对Item进行CRUD,更“领域”一点讲,你需要对Item进行持久化的操作,那么Item就一定是聚合根,那么它是哪个聚合的聚合根?就需要看应用本身的需求了。
同理,至于Category和Item是否属于同一个聚合,以及Category是否是聚合根,也要根据实际需求而定。DDD中所讨论的聚合应该是组合聚合(Composite Aggregation),而不是可共享聚合(Shareable Aggregation),因为在创建聚合的同时也需要创建聚合内部的成员。于是,从语义上讲,子部件无法脱离聚合而单独存在(就像汽车与方向盘、轮子的关系那样)。但事实上呢?现实生活中,物品就是物品,可以不给它们归类,也可以将它们分属于不同的类别,但归类也好,不归类也好,物品都是客观存在的。不因为你不给它归类,物品就消失了。
因此,在做建模的时候,我们可能需要更加注重实际应用与我们模型的距离,以便更加真实客观地反映问题本身。DDD是实践指导,不是理论,就像对待设计模式一样,我们所能做的只是借鉴,而不是照搬。
希望我的解答能够为你提供帮助。

Re:实体框架之领域驱动实践(五)

[ 2010-1-18 15:26:00 | By: ruson(游客) ]

谢谢博主的回复。
这段时间在尝试NHibernate + Spring.NET下的DDD实践。

以下为 blog主人的回复:
共同探讨,共同进步。
2008年的时候我尝试过Spring.NET+Castle ActiveRecord的DDD实践。当时我选用Castle ActiveRecord的原因是因为样品很简单,我不打算去维护NHibernate复杂的mapping XML。其实ActiveRecord是夹在Transaction Script和Domain Model之间的DDD的反模式,DDD社区中不少人指出这种做法不妥,但我觉得只要适合我的实际情况,也没什么大碍。
与Spring.NET一样,NHibernate也是一种解耦的手段。Spring.NET解耦了对象之间的依赖性,而NHibernate则解耦了对象模型与数据库模型之间的映射关系。两者目的相同:提高系统的延展性和扩充性。

posted @ 2010-07-07 09:01 dax.net 阅读(...) 评论(...) 编辑 收藏