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中的使用，介请期待！

 

回到目录