[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店
一、前言
在前面专题一中,我已经介绍了我写这系列文章的初衷了。由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广。然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网上书店,从而让大家学习DDD不再枯燥和可以看到一个DDD案例的形成历程。最后,再DDD案例完成之后,将从中抽取一个领域驱动的框架,从而大家也可以看到一个DDD框架的形成历程,这样就不至于一下子消化一整个框架和案例的知识,而是一步步消化。接下来,该专题将介绍的是:结合领域驱动设计的SOA架构来构建网上书店,本专题中并没有完成网上书店的所有页面和覆盖DDD中的所有内容,而只是一部分,后面的专题将会在本专题的网上书店进行一步步完善,通过一步步引入DDD的内容和重构来完成整个项目。
二、DDD分层架构
从概念上说,领域驱动设计架构主要分为四层,分别为:基础设施层、领域层、应用层和表现层。
- 基础结构层:该层专为其他各层提供各项通用技术框架支持。像一些配置文件处理、缓存处理,事务处理等都可以放在这里。
- 领域层:简单地说就是业务所涉及的领域对象(包括实体、值对象)、领域服务等。该层就是所谓的领域模型了,领域驱动设计提倡是富领域模型,富领域模型指的是:尽量将业务逻辑放在归属于它的领域对象中。而之前的三层架构中的领域模型都是贫血领域模型,因为在三层中的领域模型只包含业务属性,而不包含任何业务逻辑。本专题的网上书店领域模型目前还没有包含任何业务逻辑,在后期将会完善。
实体可以认为对应于数据库的表,而值对象一般定义在实体类中。
- 应用层:该层不包含任何领域逻辑,它主要用来对任务进行协调,它构建了表现层和领域层的桥梁。SOA架构就是在该层进行实现的。
- 表现层:指的是用户界面,例如Asp.net mvc网站,WPF、Winform和控制台等。它主要用来想用户展现内容。
下面用一个图来形象展示DDD的分层架构:
本系列介绍的领域驱动设计实战,则自然少了领域驱动设计分层架构的实现了,上面简单介绍了领域驱动的分层架构,接下来将详细介绍在网上书店中各层是如何去实现的。
三、网上书店领域模型层的实现
在应用领域驱动设计的思想来构建一个项目,则第一步就是了解需求,明白项目的业务逻辑,了解清楚业务逻辑后,则把业务逻辑抽象成领域对象,领域对象所放在的位置也就是领域模型层了。该专题介绍的网上书店主要完成了商品所涉及的页面,包括商品首页,单个商品的详细信息等。所以这里涉及的领域实体包括2个,一个是商品类,另外一个就是类别类,因为在商品首页中,需要显示所有商品的类别。在给出领域对象的实现之前,这里需要介绍领域层中所涉及的几个概念。
- 聚合根:聚合根也是实体,但与实体不同的是,聚合根是由实体和值对象组成的系统边界对象。举个例子来说,例如订单和订单项,根据业务逻辑,我们需要跟踪订单和订单项的状态,所以设计它们都为实体,但只有订单才是聚合根对象,而订单项不是,因为订单项只有在订单中才有意义,意思就是说:用户不能直接看到订单项,而是先查询到订单,然后再看到该订单下的订单项。所以聚合根可以理解为用户直接操作的对象。在这里商品类和类别类都是一个聚合根。
根据面向接口编程原则,我们在领域模型中应该定义一个实体接口和聚合根接口,而因为聚合根也是属于实体,所以聚合根接口继承于实体接口,而商品类和类别类都是聚合根,所以它们都实现聚合根接口。如果像订单项只是实体不是聚合根的类则实现实体接口。有了上面的分析,则领域模型层的实现也就自然出来了,下面是领域对象的具体实现:
// 领域实体接口 public interface IEntity { // 当前领域实体的全局唯一标识 Guid Id { get; } }
// 聚合根接口,继承于该接口的对象是外部唯一操作的对象 public interface IAggregateRoot : IEntity { }
// 商品类 public class Product : AggregateRoot { public string Name { get; set; } public string Description { get; set; } public decimal UnitPrice { get; set; } public string ImageUrl { get; set; } public bool IsNew{ get; set; } public override string ToString() { return Name; } }
// 类别类 public class Category : AggregateRoot { public string Name { get; set; } public string Description { get; set; } public override string ToString() { return this.Name; } }
另外,领域层除了实现领域对象外,还需要定义仓储接口,而仓储层则是对仓储接口的实现。仓储可以理解为在内存中维护一系列聚合根的集合,而聚合根不可能一直存在于内存中,当它不活动时会被持久化到数据中。而仓储层完成的任务是持久化聚合根对象到数据或从数据库中查询存储的对象来重新创建领域对象。
仓储层有几个需要明确的概念:
- 仓储里面存放的对象一定是聚合根,因为领域模型是以聚合根的概念去划分的,聚合根就是我们操作对象的一个边界。所以我们都是对某个聚合根进行操作的,而不存在对聚合内的值对象进行操作。因此,仓储只针对聚合根设计。
- 因为仓储只针对聚合根设计,所以一个聚合根需要实现一个仓储。
- 不要把仓储简单理解为DAO,仓储属于领域模型的一部分,代表了领域模型向外界提供接口的一部分,而DAO是表示数据库向上层提供的接口表示。一个是针对领域模型而言,而另一个针对数据库而言。两者侧重点不一样。
- 仓储分为定义部分和实现部分,在领域模型中定义仓储的接口,而在基础设施层实现具体的仓储。这样做的原因是:由于仓储背后的实现都是在和数据库打交道,但是我们又不希望客户(如应用层)把重点放在如何从数据库获取数据的问题上,因为这样做会导致客户(应用层)代码很混乱,很可能会因此而忽略了领域模型的存在。所以我们需要提供一个简单明了的接口,供客户使用,确保客户能以最简单的方式获取领域对象,从而可以让它专心的不会被什么数据访问代码打扰的情况下协调领域对象完成业务逻辑。这种通过接口来隔离封装变化的做法其实很常见。由于客户面对的是抽象的接口并不是具体的实现,所以我们可以随时替换仓储的真实实现,这很有助于我们做单元测试。在本专题的案例中,我们把仓储层的实现单独从基础设施层拎出来了,作为一个独立的层存在。这也就是为什么DDD分层中没有定义仓储层啊,而本专题的案例中多了一个仓储层的实现。
- 仓储在设计查询接口时,会经常用到规约模式(Specification Pattern)。本专题的案例中没有给出,这点将会在后面专题添加上去。
- 仓储一般不负责事务处理,一般事务处理会交给“工作单元(Unit Of Work)”去处理,同样本专题也没有涉及工作单元的实现,这点同样会在后面专题继续完善。这里列出来让大家对后面的专题可以有个清晰的概念,而不至于是空穴来风的。
介绍完仓储之后,接下来就在领域层中定义仓储接口,因为本专题中涉及到2个聚合根,则自然需要实现2个仓储接口。根据面向接口编程原则,我们让这2个仓储接口都实现与一个公共的接口:IRepository接口。另外仓储接口还需要定义一个仓储上下接口,因为在Entity Framework中有一个DbContex类,所以我们需要定义一个EntityFramework上下文对象来对DbContex进行包装。也就自然有了仓储上下文接口了。经过上面的分析,仓储接口的实现也就一目了然了。
// 仓储接口 public interface IRepository<TAggregateRoot> where TAggregateRoot :class, IAggregateRoot { void Add(TAggregateRoot aggregateRoot); IEnumerable<TAggregateRoot> GetAll(); // 根据聚合根的ID值,从仓储中读取聚合根 TAggregateRoot GetByKey(Guid key); }
public interface IProductRepository : IRepository<Product> { IEnumerable<Product> GetNewProducts(int count = 0); }
public interface IProductRepository : IRepository<Product> { IEnumerable<Product> GetNewProducts(int count = 0); }
// 仓储上下文接口 public interface IRepositoryContext { }
这样我们就完成了领域层的搭建了,接下面,我们就需要对领域层中定义的仓储接口进行实现了。我这里将仓储接口的实现单独弄出了一个层,当然你也可以放在基础设施层中的Repositories文件夹中。不过我看很多人都直接拎出来的。我这里也是直接作为一个层。
四、网上书店Repository(仓储)层的实现
定义完仓储接口之后,接下来就是在仓储层实现这些接口,完成领域对象的序列化。首先是产品仓储的实现:
// 商品仓储的实现 public class ProductRepository : IProductRepository { #region Private Fields private readonly IEntityFrameworkRepositoryContext _efContext; #endregion #region Public Properties public IEntityFrameworkRepositoryContext EfContext { get { return this._efContext; } } #endregion #region Ctor public ProductRepository(IRepositoryContext context) { var efContext = context as IEntityFrameworkRepositoryContext; if (efContext != null) this._efContext = efContext; } #endregion public IEnumerable<Product> GetNewProducts(int count = 0) { var ctx = this.EfContext.DbContex as OnlineStoreDbContext; if (ctx == null) return null; var query = from p in ctx.Products where p.IsNew == true select p; if (count == 0) return query.ToList(); else return query.Take(count).ToList(); } public void Add(Product aggregateRoot) { throw new NotImplementedException(); } public IEnumerable<Product> GetAll() { var ctx = this.EfContext.DbContex as OnlineStoreDbContext; if (ctx == null) return null; var query = from p in ctx.Products select p; return query.ToList(); } public Product GetByKey(Guid key) { return EfContext.DbContex.Products.First(p => p.Id == key); } }
接下来是类别仓储的实现:
// 类别仓储的实现 public class CategoryRepository :ICategoryRepository { #region Private Fields private readonly IEntityFrameworkRepositoryContext _efContext; public CategoryRepository(IRepositoryContext context) { var efContext = context as IEntityFrameworkRepositoryContext; if (efContext != null) this._efContext = efContext; } #endregion #region Public Properties public IEntityFrameworkRepositoryContext EfContext { get { return this._efContext; } } #endregion public void Add(Category aggregateRoot) { throw new System.NotImplementedException(); } public IEnumerable<Category> GetAll() { var ctx = this.EfContext.DbContex as OnlineStoreDbContext; if (ctx == null) return null; var query = from c in ctx.Categories select c; return query.ToList(); } public Category GetByKey(Guid key) { return this.EfContext.DbContex.Categories.First(c => c.Id == key); } }