DDD~领域层

回到目录

再论Domain与Infrastructure

在面向领域的设计中，领域层（Domain）实现上是位于最底层的，其它层有对它的引用，包括基础设施层(Infrastructure)也是去引用领域层的，我认为，这是对的，事实上，在Domain中会规定如何去进行数据持久化的操作，包括方法名，方法签名等等，而采用哪种架构去实现这种持久化的方法则是Infrastructure层需要做的，这种设计绝对是把领域，业务放在第一位的，完全符合Eric 的DDD。

Domain.Core Layer & Domain Layer

我们在进行软件设计时，一个习惯就是把仅供代码抽象出来，这是对的，也是符合标准的，对于domain层我们会把与具体领域无关的代码抽象成一个domain.core，这个项目位于整个ＤＤＤ解决方案的最底层，而具体的domain则会引入它，看一下我们的ＤＤＤ中的domain层

domain.core中有数据持久化的规范，规约实现Specification及一些公用的功能代码。

具体的domain项目中包括三部分内容，具体业务规范（如产品业务规范Products），数据模型POCO实体，用于网络传输的ＤＴＯ实体（这部分可以单拿出来，本例直接放在了实体层），我们先来看一下products这个业务规范：

IProductRepository：它是产品实体的数据持久化规范，Infrastructure层会去实现它，这里不会关心Infrastructure是采用linq to sql还是ef，我只规定要做什么，至少怎么去做，由Infrastructure自己去决定！

　　public interface IProductRepository : IExtensionRepository<Product>
    {
        /// <summary>
        /// 获取产品列表
        /// </summary>
        /// <returns></returns>
        IQueryable<Product> GetProduct();

        /// <summary>
        /// 建立产品
        /// </summary>
        void AddProduct(Product entity);

        /// <summary>
        /// 修改产品
        /// </summary>
        void ModifyProduct(System.Linq.Expressions.Expression<Action<Product>> entity);
    }

ProductSpecification：这是一个与业务息息相关的规约类，它会根据具体业务去设计每一个业务的具体规约
　

　　/// <summary>
    /// 通过用户信息得到他的订单列表
    /// </summary>
    public class ProductSpecification : Specification<Product>
    {
        string _productName = default(string);
        public ProductSpecification(string productName)
        {
            _productName = productName;
        }
        public override Expression<Func<Product, bool>> SatisfiedBy()
        {
            Specification<Product> spec = new TrueSpecification<Product>();
            if (string.IsNullOrWhiteSpace(_productName))
                spec &= new DirectSpecification<Product>(o => o.ProductName.Contains(_productName));
            return spec.SatisfiedBy();
        }
    }

网络传输对象ＤＴＯ，它是在进行ＷＥＢ通讯时为了减少网站负载，而提出的新的实体层，将与本服务有关的实体属性提出，形成一个新的实体，这在ＳＯＡ服务

中用的比较多。

　　[DataContract]
    public class ProductDTO
    {
        [DataMember]
        [DisplayName("商品ID")]
        public int ProductID { get; set; }
        [DataMember]
        [DisplayName("商品名称")]
        public string ProductName { get; set; }
        [DataMember]
        [DisplayName("建立日期")]
        public System.DateTime CreateDate { get; set; }
        [DataMember]
        public int SaleCount { get; set; }
        [DataMember]
        public Nullable<int> ClickCount { get; set; }
        [DataMember]
        [DisplayName("产品描述")]
        public string Info { get; set; }
        [DataMember]
        public int UserID { get; set; }
        [DataMember]
        [DisplayName("销售价格")]
        public decimal SalePrice { get; set; }
        [DataMember]
        [DisplayName("折扣")]
        public int Discount { get; set; }
    }

数据模型ＥＤＭＸ，这种模块我们称为entity frameworks模型，也叫ＥＦ模型，它可以把物理数据库映射到ＥＤＭＸ文件中，它是以ＸＭＬ形式保存的，而我们

的ＰＯＣＯ简单数据实体也可以由工具自动生成，这些实体与原始数据表一一对应。ef poco 模型实体采用partial　class方便开发人员以后对实体类进行扩展。

　　public partial class Product
    {
        public Product()
        {
            this.ProductDetail = new HashSet<ProductDetail>();
        }
    
        public int ProductID { get; set; }
        public string ProductName { get; set; }
        public System.DateTime CreateDate { get; set; }
        public int SaleCount { get; set; }
        public Nullable<int> ClickCount { get; set; }
        public string Info { get; set; }
        public int UserID { get; set; }
        public decimal SalePrice { get; set; }
        public int Discount { get; set; }
        public System.DateTime UpdateDate { get; set; }
    
        public virtual User_Info User_Info { get; set; }
        public virtual ICollection<ProductDetail> ProductDetail { get; set; }
    }

最后，我们看一个domain与Infrastructure之间的数据通信，它们一般使用ＩＯＣ容器进行实现，像Autofac和Unity都是不错的选择，而unity是一个强大的工具

集，它不仅包括IOC的功能，而且还提供了对AOP的实现！下次我们将着重介绍一下Unity在DDD中的使用，介请期待！

 

回到目录