首页 > 代码库 > DDD建模案例----“视频课程”场景

DDD建模案例----“视频课程”场景

  接触领域驱动设计DDD有一年多的时间了,中间看过不少书,参与过一些讨论(ENode QQ群)。目前对DDD的认知还停留在理论阶段,所以对领域建模非常感兴趣,这里说的建模是指以DDD的思想为指导再加上DDD的工具,比如聚合、实体、值对象等等。

  昨天有群友分享了一个建模的案例,我想在这儿记录下来,有两个目的:1、为自己学习DDD储存素材  2、锻炼自己写文章的能力

  关于DDD中的一些概念,请见如下文章链接:

  http://www.cnblogs.com/ivanzheng/p/5533162.html(Ivan翻译)

  http://www.cqrs.nu/Faq(这是原文链接,英文好的可以直接读这个)

 

场景


  大家肯定都听说过视频课程网站吧,比如慕课网。这儿要说的场景跟这个网站的后台管理比较相关。比如,课程的作者可以上传一些课程视频(Video)到该网站,然后再创建一个课程(Course),把之前上传的视频放到该课程下,等所有的课程视频都审核通过了,则就可以发布这个课程了,学习者就可以在网上看到该课程。

  上面那段话只是对“视频课程”场景做了大致的描述,下面我将逐条以用例(Use Case)的方式做一个列表:

  1. 用户可以把一个或多个视频上传到网站,并等待审核
  2. 用户创建了一个课程,比如叫《Lisp从入门到放弃》
  3. 用户把一个或多个视频关联到该课程下(关联的时候不要求视频是已审核状态)
  4. 用户发布创建的课程时,要求其下至少关联3个以上的视频,且这些视频必须是已审核通过。只有满足了这两个要求才能发布课程
  5. 一个视频可以放到多个课程下

  从Use Case中可以很容易的得到这几个概念(名词):视频、课程。(因为本次建模只关注课程与视频的关系,不考虑用户);业务的行为概念也很容易得到:审核、发布。

  业务模型很简单,课程和视频是典型的多对多关系。

分析


  通过场景可以分析出如下两个实体:视频、课程

  必须满足的业务规则:

      1、发布课程时,要求该课程下的关联的视频个数≥3

      2、发布课程时,其下的所有视频必须都是已经审核通过的状态

  很显然,在场景描述时,我们隐含的表达了以下这些概念:

      1、视频可以单独上传,管理,审核等,从业务规则上来看,它不依赖于任何课程的状态

      2、课程可以单独创建,在发布时需要依赖视频的个数和状态

  所以,视频显然是一个聚合根。在现有的业务场景中,课程也是一个聚合根,这个应该没有歧义。业务规则1和2也是在课程这个聚合下体现,并保证业务规则被满足。

设计


  有一个最容易想到的非DDD的设计,代码可能如下:

 

class Course    {        public string Id { get; }        public ICollection<Video> Videos { get; }        public void Publish()        {            if (Videos.Count < 3)                throw Exception("One course must associate 3 videos.");            if (Videos.Any(v => !v.Approved))                throw Exception("All videos need to be approved.");            ...        }    }    class Video    {        public string Id { get; }        public bool Approved { get; set; }        public ICollection<Course> Courses { get; }    }

  先不说这个设计的好坏,我们直接来看从DDD的角度如何设计这两个聚合根。

  首先一点,聚合之间不可直接引用(内存引用),必须以Id的方式引用,因为根据定义聚合是不允许接触到他们外部的. (如果允许了那意味着聚合不再是一个事务边界, 我们也不再能充分的推导出聚合有能力确保他的不变性;这也将妨碍到聚合的分片处理)

  因为课程发布时,需要验证其下所关联视频个数和是否全部审核,所以需要一个视频信息的实体聚合在课程下。

class Course    {        public string Id { get; }        public ICollection<VideoInfo> VideoInfos { get; } //视频信息的实体集合        public void Publish()        {            if (VideoInfos.Count < 3)                throw Exception("One course must associate 3 videos.");            if (VideoInfos.Any(v => !v.Approved))                throw Exception("All videos need to be approved.");            ...        }    }        //视频信息,至少包含视频Id和是否已审核的状态    class VideoInfo    {        public string VideoId { get; }        public bool VideoApproved { get; set; }    }    class Video    {        public string Id { get; }        public bool Approved { get; set; }        public ICollection<string> Courses { get; } //Course Id的集合    }

 

  在CQRS架构风格下,且为了保证高并发及性能,聚合之间采用最终一致性,且聚合之间的交互通过Saga来完成。当视频审核通过后,视频聚合根发消息通知所有关联它的课程,以便更新课程中的VideoInfo的状态,所以Video聚合根下要有课程Id集合的原因。

  

总结


  在DDD中,有个例子经常被用来讲解聚合、实体、值对象的概念,那就是电商领域的订单(Order)、订单项(OrderLine)、商品(Product)。其实上面的场景很类似于Order、OrderLine、Product之间的关系,课程相当于Order,视频相当于Product,视频信息相当于OrderLine。这也许就是举一反三的体现吧。

  注:此图来源于汤雪华的博客 

技术分享

 

  通过写文章才知道自己的文字功底有多差,这篇随笔的形式大于内容,希望读者朋友见谅。本篇文章的内容几乎来自于ENode群中的聊天记录,我将图片贴到下方,也许看这个更有启发。

  欢迎大家加入ENode群讨论DDD和牛逼的ENode框架,QQ群号:185916873。群主(汤雪华,netfocus)博客:http://www.cnblogs.com/netfocus/

技术分享

 

 技术分享

技术分享

 

 

  

DDD建模案例----“视频课程”场景