[.NET领域驱动设计实战系列]专题二：结合领域驱动设计的面向服务架构来搭建网上书店-低调大师

[.NET领域驱动设计实战系列]专题二：结合领域驱动设计的面向服务架构来搭建网上书店

2017-12-04 516

原文: [.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);
        }
    }

View Code

　　接下来是类别仓储的实现：

// 类别仓储的实现
    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);
        }
    }

View Code

　　由于后期除了实现基于EF仓储的实现外，还想实现基于MongoDb仓储的实现，所以在仓储层中创建了一个EntityFramework的文件夹，并定义了一个IEntityFrameworkRepositoryContext接口来继承于IRepositoryContext接口，由于EF中持久化数据主要是由DbContext对象来完成了，为了有自己框架模型，我在这里定义了OnlineStoreDbContext来继承DbContext，从而用OnlineStoreDbContext来对DbContext进行了一次包装。经过上面的分析之后，接下来对于实现也就一目了然了。首先是OnlineStoreDbContext类的实现：

public sealed class OnlineStoreDbContext : DbContext
    {
        #region Ctor
        public OnlineStoreDbContext()
            : base("OnlineStore")
        {
            this.Configuration.AutoDetectChangesEnabled = true;
            this.Configuration.LazyLoadingEnabled = true;
        }
        #endregion 

        #region Public Properties

        public DbSet<Product> Products 
        { 
            get { return this.Set<Product>(); }
        }

        public DbSet<Category> Categories
        {
            get { return this.Set<Category>(); }
        }

        // 后面会继续添加属性，针对每个聚合根都会定义一个DbSet的属性
        // ...
        #endregion
    }

　　接下来就是IEntityFrameworkRepositoryContext接口的定义以及它的实现了。具体代码如下所示：

public interface IEntityFrameworkRepositoryContext : IRepositoryContext
    {
        #region Properties
        OnlineStoreDbContext DbContex { get; }
        #endregion 
    }

 public class EntityFrameworkRepositoryContext : IEntityFrameworkRepositoryContext
    {
        // 引用我们定义的OnlineStoreDbContext类对象
        public OnlineStoreDbContext DbContex
        {
            get { return new OnlineStoreDbContext(); }
        }
    }

　　这样，我们的仓储层也就完成了。接下来就是应用层的实现。

五、网上书店应用层的实现

　　应用层应用了面向服务结构进行实现，采用了微软面向服务的实现WCF来完成的。网上书店的整个架构完全遵循着领域驱动设计的分层架构，用户通过UI层（这里实现的是Web页面）来进行操作，然后UI层调用应用层来把服务进行分发，通过调用基础设施层中仓储实现来对领域对象进行持久化和重建。这里应用层主要采用WCF来实现的，其中引用了仓储接口。针对服务而言，首先就需要定义服务契约了，这里我把服务契约的定义单独放在了一个服务契约层，当然你也可以在应用层中创建一个服务契约文件夹。首先就去看看服务契约的定义：

// 商品服务契约的定义
    [ServiceContract(Namespace="")]
    public interface IProductService
    {
        #region Methods
        // 获得所有商品的契约方法
        [OperationContract]
        IEnumerable<Product> GetProducts();

        // 获得新上市的商品的契约方法
        [OperationContract]
        IEnumerable<Product> GetNewProducts(int count);

        // 获得所有类别的契约方法
        [OperationContract]
        IEnumerable<Category> GetCategories();

        // 根据商品Id来获得商品的契约方法
        [OperationContract]
        Product GetProductById(Guid id);

        #endregion
    }

View Code

　　接下来就是服务契约的实现，服务契约的实现我放在应用层中，具体的实现代码如下所示：

 // 商品服务的实现
    public class ProductServiceImp : IProductService
    {
        #region Private Fields
        private readonly IProductRepository _productRepository;
        private readonly ICategoryRepository _categoryRepository;
        #endregion 

        #region Ctor
        public ProductServiceImp(IProductRepository productRepository, ICategoryRepository categoryRepository)
        {
            _categoryRepository = categoryRepository;
            _productRepository = productRepository;
        }

        #endregion

        #region IProductService Members
        public IEnumerable<Product> GetProducts()
        {
            return _productRepository.GetAll();
        }

        public IEnumerable<Product> GetNewProducts(int count)
        {
            return _productRepository.GetNewProducts(count);
        }

        public IEnumerable<Category> GetCategories()
        {
            return _categoryRepository.GetAll();
        }

        public Product GetProductById(Guid id)
        {
            var product = _productRepository.GetByKey(id);
            return product;
        }

        #endregion  
    }

View Code

　　最后就是创建WCF服务来调用服务契约实现了。创建一个后缀为.svc的WCF服务文件，WCF服务的具体实现如下所示：

// 商品WCF服务
    public class ProductService : IProductService
    {
        // 引用商品服务接口
        private readonly IProductService _productService;

        public ProductService()
        {
            _productService = ServiceLocator.Instance.GetService<IProductService>();
        }

        public IEnumerable<Product> GetProducts()
        {
            return _productService.GetProducts();
        }

        public IEnumerable<Product> GetNewProducts(int count)
        {
            return _productService.GetNewProducts(count);
        }

        public IEnumerable<Category> GetCategories()
        {
            return _productService.GetCategories();
        }

        public Product GetProductById(Guid id)
        {
            return _productService.GetProductById(id);
        }
    }

　　到这里我们就完成了应用层面向服务架构的实现了。从商品的WCF服务实现可以看到，我们有一个ServiceLocator的类。这个类的实现采用服务定位器模式，关于该模式的介绍可以参考dax.net的服务定位器模式的介绍。该类的作用就是调用方具体的实例，简单地说就是通过服务接口定义具体服务接口的实现，将该实现返回给调用者的。这个类我这里放在了基础设施层来实现。目前基础设施层只有这一个类的实现，后期会继续添加其他功能，例如缓存功能的支持。

　　另外，在这里使用了Unity依赖注入容器来对接口进行注入。主要的配置文件如下所示：

<configuration>
  <configSections>
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework"/>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>
  </configSections>
  
  <!-- Entity Framework 配置信息-->
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="Data Source=(LocalDb)\v11.0; Initial Catalog=OnlineStore; Integrated Security=True; Connect Timeout=120; MultipleActiveResultSets=True; AttachDBFilename=|DataDirectory|\OnlineStore.mdf"/>
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>
 
  <!--Unity的配置信息-->
  <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
    <container>
      <!--仓储接口的注册-->
     
      <register type="OnlineStore.Domain.Repositories.IRepositoryContext, OnlineStore.Domain" mapTo="OnlineStore.Repositories.EntityFramework.EntityFrameworkRepositoryContext, OnlineStore.Repositories"/>
      <register type="OnlineStore.Domain.Repositories.IProductRepository, OnlineStore.Domain" mapTo="OnlineStore.Repositories.EntityFramework.ProductRepository, OnlineStore.Repositories"/>
      <register type="OnlineStore.Domain.Repositories.ICategoryRepository, OnlineStore.Domain" mapTo="OnlineStore.Repositories.EntityFramework.CategoryRepository, OnlineStore.Repositories"/>
      
      <!--应用服务的注册-->
      <register type="OnlineStore.ServiceContracts.IProductService, OnlineStore.ServiceContracts" mapTo="OnlineStore.Application.ServiceImplementations.ProductServiceImp, OnlineStore.Application"/>
    </container>
  </unity>
  
  <appSettings>
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true"/>
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.5"/>
    <httpRuntime targetFramework="4.5.1"/>
  </system.web>
  <!--WCF 服务的配置信息-->
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service name="OnlineStore.Application.ServiceImplementations.ProductServiceImp" behaviorConfiguration="">
        <endpoint address="" binding="wsHttpBinding" contract="OnlineStore.ServiceContracts.IProductService"/>
        <!--<endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />-->
      </service>
    </services>
    
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/>
  </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <!--
        To browse web app root directory during debugging, set the value below to true.
        Set to false before deployment to avoid disclosing web app folder information.
      -->
    <directoryBrowse enabled="true"/>
  </system.webServer>
</configuration>

View Code

六、基础设施层的实现

　　基础设施层在本专题中只包含了服务定位器的实现，后期会继续添加对其他功能的支持，ServiceLocator类的具体实现如下所示：

 // 服务定位器的实现
    public class ServiceLocator : IServiceProvider
    {
        private readonly IUnityContainer _container;
        private static ServiceLocator _instance = new ServiceLocator();

        private ServiceLocator()
        {
            _container = new UnityContainer();
            _container.LoadConfiguration();
        }

        public static ServiceLocator Instance
        {
            get { return _instance; }
        }

        #region Public Methods

        public T GetService<T>()
        {
            return _container.Resolve<T>();
        }

        public IEnumerable<T> ResolveAll<T>()
        {
            return _container.ResolveAll<T>();
        }

        public T GetService<T>(object overridedArguments)
        {
            var overrides = GetParameterOverrides(overridedArguments);
            return _container.Resolve<T>(overrides.ToArray());
        }

        public object GetService(Type serviceType, object overridedArguments)
        {
            var overrides = GetParameterOverrides(overridedArguments);
            return _container.Resolve(serviceType, overrides.ToArray());
        }

        #endregion 

        #region Private Methods
        private IEnumerable<ParameterOverride> GetParameterOverrides(object overridedArguments)
        {
            var overrides = new List<ParameterOverride>();
            var argumentsType = overridedArguments.GetType();
            argumentsType.GetProperties(BindingFlags.Public | BindingFlags.Instance)
                .ToList()
                .ForEach(property =>
                {
                    var propertyValue = property.GetValue(overridedArguments, null);
                    var propertyName = property.Name;
                    overrides.Add(new ParameterOverride(propertyName, propertyValue));
                });
            return overrides;
        }
        #endregion 

        #region IServiceProvider Members

        public object GetService(Type serviceType)
        {
            return _container.Resolve(serviceType);
        }

        #endregion 
    }

View Code

七、UI层的实现

　　根据领域驱动的分层架构，接下来自然就是UI层的实现了，这里UI层的实现采用Asp.net MVC 技术来实现的。UI层主要包括商品首页的实现，和详细商品的实现，另外还有一些附加页面的实现，例如，关于页面，联系我们页面等。关于UI层的实现，这里就不一一贴出代码实现了，大家可以在最后的源码链接自行下载查看。

八、系统总体架构

　　经过上面的所有步骤，本专题中的网上书店构建工作就基本完成了，接下来我们来看看网上书店的总体架构图（这里架构图直接借鉴了dax.net的图了，因为本系列文章也是对其Byteart Retail项目的剖析过程）：

　　最后附上整个解决方案的结构图：

九、网上书店运行效果

　　实现完之后，大家是不是都已经迫不及待地想看到网上书店的运行效果呢？下面就为大家来揭晓，目前网上书店主要包括2个页面，一个是商品首页的展示和商品详细信息的展示。首先看下商品首页的样子吧：

　　图书的详细信息页面：

十、总结

　　到这里，本专题的内容就介绍完了，本专题主要介绍面向领域驱动设计的分层架构和面向服务架构。然后结合它们在网上书店中进行实战演练。在后面的专题中我会在该项目中一直进行完善，从而形成一个完整了DDD案例。在接下来的专题会对仓储的实现应用规约模式，在应用之前，我会先写一个专题来介绍规约模式来作为一个准备工作。

　　GitHub 开源地址：https://github.com/lizhi5753186/OnlineStore。

微信关注我们

原文链接：https://yq.aliyun.com/articles/332115

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

伟大架构师的秘密

By Don Awalt and Rick McUmber RDA Corporation 企业架构师正受到其所面临的大量复杂性的挑战。开发一个能够自动处理企业任务的独立的部门应用程序是一回事。而设计并组成一个支持上万 IT 使用者的满是应用程序、服务器和数据库（全都支持多种企业活动）的 IT 实验室全球网络，则完全是另外一回事。要组合这些复杂性，IT 网络必须随时可用、响应迅速并保护企业宝贵的信息资产。除所有这些之外，IT 网络还必须足够灵活以支持企业永远变化的需要，并且采用出现的新技术。将抽象层次应用到 IT 解决方案一些架构师在这种复杂性方面明显非常出色，而且在不断进步。在我们的职业生涯中，能与一些真正伟大的分析师和架构师并肩工作是非常幸运的。反思这些经验，我们已经分析出是什么造就了杰出的架构师。无一例外，所有伟大的架构师都掌握了在截然不同的抽象层次上概念化解决方案的技能。通过将解决方案组织到离散的层次，架构师可以将精力集中在解决方案的单个方面而忽略所有剩余的复杂性。他们一旦稳定了解决方案的某个部分，接下来就能继续处理其他方面，从而不断地将层次发展并完善到最终可以被实现的粘合...

2017-12-04

611

EF架构~引入规约(Specification)模式，让程序扩展性更强

规约(Specification)模式：第一次看到这东西是在microsoft NLayer项目中，它是微软对DDD的解说，就像petshop告诉了我们MVC如何使用一样，这个规约模式最重要的作用是实现了查询语句与查询条件的分离，查询语句在底层是稳定的，不变的，而查询条件是和具体业务，具体领域有关的，是易变的，如果我们为每一个领域的每一个新需求都写一个新的方法，那就会出现很多重复的代码，不利于程序的最终扩展！下面我们来看一个经典例子一个IOrderRepository的接口，定义了一个订单仓储 Order_Info GetOrder_InfoById(int orderID); List<Order_Info> GetOrder_Info(DateTime from, DateTime to); List<Order_Info> GetOrder_InfoByUser(int userID); 代码本身没有任何问题，你只要去实现它就可以了，当一个新的需求到了之后，你的接口要被扩展（这是不被提倡的，一般我们会新建一个接口），然后修改原来的实现类，去实现接口新...

2017-12-04

585

发表评论

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。