领域驱动设计，让程序员心中有码（七）

领域驱动设计- 让程序员心中有码（七）

-设计原则和设计模式，互联网开发者们共同的追求

前言

　　多年来，笔者一直从事传统软件企业的软件开发和项目管理工作。笔者发现在众多的传统软件企业中，评判优秀开发者的标准往往是技能的熟练程度，基本上都是以梭代码的速度论英雄。有人评价说，这种开发可以称之为cv编程，即ctrl+c和ctrl+v编程为主。这种开发往往对开发者的技能要求并没有想象中的那么高，由于工时和合同的限制，不得不压缩开发时间，通过靠密集的劳动力资源、较高的工作强度来完成项目的开发。这种模式，通过简单的复用历史代码，可以更快的输出结果，对于中小型企业和一些外包企业来说，也意味着更快的项目完成速度、而越快做完项目，也意味着可以越快收回合同款，尽快开始下一个项目。

　　然而，也必须承认，在这种模式下，代码的质量取决于项目管理者对于技术和代码的把握能力，如果摊上不懂技术的项目管理者以及对于代码质量没有要求的研发人员，可能最终输出的代码，将成为一团乱麻，只能在一个个项目中无穷次的积累，直到遇到一群优秀的开发人员费劲心力把体系重构为止。

　　而当今互联网时代下，面向互联网的应用开发，不再追求短期成效，更在乎长期技术的沉淀，这个过程中，也对开发者提出了更高的要求。互联网行业的开发者，不仅仅要求代码梭得快，还在乎编写代码编写的质量，谁能编写出更加优美的代码，往往也更容易受人欢迎。于是，作为优美代码代名词的SOLID设计原则和很多种设计模式实际上成为了非常基础的一种能力，甚至于许多资深的开发者，经常会乐此不疲的进行各种代码的重构，也是期待能够更好的将设计模式揉碎了，应用到代码中，更好的实现高内聚、低耦合的目标。

《head first》中的工厂模式

　　在著名小红书《Head First》一书中，描述了多种设计模式，这些由资深IT技术大牛们抽象化出来的最佳代码实践，初读起来也许简单明了，但是细细品味起来，却意味深长。

　　在传统软件开发实践工程中，往往会下意识的使用New关键字产生对象实例。通过这种方式进行代码的编写，固然会带来代码上的开发速度，但是同样也会给对象的生成带来一些问题。例如，对象的构造，往往附带了许多复杂的条件：如需要进行一些初始值的设置，如需要初始化与之相关的子类，或者需要预先执行许多初始化方法，那么就可能意味着代码的构造中会产生一系列复杂、与主流程无关的代码。如何让轻松方便的构造代码、而不去关心具体的实现细节呢？

　　工厂模式成为解决问题的方案，通过工厂模式，适当的创建接口，将代码中的具体过程进行屏蔽，从而提高了代码的灵活性。又分为静态工厂、简单工厂模式、工厂方法模式、抽象工厂模式等多种不同的模式。例如，我们可能会编写一段下面的代码。

640?wx_fmt=gif

 1 public abstract class FactoryPizzaStore 2 { 3         public Pizza OrderPizza(string type) 4         { 5  6             Pizza pizza = CreatePizza(type); 7             return pizza; 8         } 9         public abstract Pizza CreatePizza(string type);10 }

640?wx_fmt=gif

　　我们可以看到，这只是一段最普通的工厂代码，定义了一个抽象对象，如果需要实现成员，只需继承此对象，并重载方法，这种方法可以非常便捷的将内部对象的创建过程进行封装，实现了代码内聚性的显著提高。

领域驱动中的工厂模式和仓储模式

在领域驱动中，将工厂模式引入其中，让其产生了不同的含义。在上一章，我们了解到，随着软件系统复杂性的显著提高，维护模型实例的生命周期变成了一件非常困难的事情，因此通过引入一个聚合Aggregate对象，可以有效的将复杂的模型复杂的生命周期的各个阶段进行封装，通过一系列固定的规则，实现了对数据更加的控制。而这种控制，则是通过工厂模式和仓储模式来实现的。这两种模式，实现了对Aggregate对象的操作，实现了复杂的生命周期转换复杂性的良好封装。

领域工厂模式

　　一个复杂的软件系统，往往如同生产一台汽车，它由许多个不同的部件组成，每个部件间通过一系列复杂的协同运动来实现整体的职能。对于用户而言，汽车是如何装配的，并不是他所关心的问题，他只在乎如何驾驶这辆汽车。这意味着，装配过程，应该与对象要执行的工作分开。软件系统同样如此，我们设计了一个复杂的聚合对象，这个对象内部有大量的实体或者值对象。如果开发者需要使用这个对象，必须按照一系列规则来进行操作。

在这个聚合对象的生命周期中，如果将创建的过程按照调用的场景，分拆到不同的环节中，可能使代码的耦合性急剧提高，带来的将是后期高昂的更改成本。

　　在领域驱动设计中，复杂对象的创建过程往往是领域层的核心职能，但是，对于这个复杂对象创建过程，又显然不能有简单的Service对象来实现，因此，需要引入工厂模式。封装创建复杂对象或聚合对象

的全部规则，并通过提供相关接口、创建对象的抽象视图，让创建的过程符合规则。

　　在领域工厂模式中，往往有以下要求：

1、创建过程的原子性、满足创建所需的所有规则。由于我们引入工厂的目的，是为了将复杂的常见过程进行封装，因此我们应当确保创建过程要产生一致状态的对象。例如创建实体，应当满足聚合的全部规则、创建值对象，应该被设置为默认的参数，如果无法创建参数，应该抛出异常，或者提供处理机制，确保不会影响代码的执行。

2、工厂模式是一种抽象对象，而不是具体对象。意味着这个过程，不会产生具体对象，也就避免了与下层对象间不必要的耦合。

工厂模式不仅仅可以应用于对象生命周期的开始阶段，也可以在对象的重建过程中发挥作用，例如在使用关系型数据库和非关系数据库组成的复杂体系中，通过对象映射技术，可以实现对现有数据的装载。

领域仓储对象

　　在软件系统研发过程中，我们通常需要使用SQL语句，直接调用基础设施层中的某个方法，实现了一系列数据转换。有时候，我们会引入AutoMap组件，实现从实体层到模型层对象的封装，这种模式广泛存在于我们的开发过程中，但是如果直接访问基础设施层，则可能增加对于数据库不必要的操作，并导致模型的价值可有可无。而且随着开发过程的推进，有可能会倾向于直接使用多次遍历的方式，提取具体对象，而忽略了Aggregate，并使得实体层成为单纯的数据容器。

　　因此，通过引入仓储模式，可以为我们的实现过程提供便利。通过仓储模式，封装一系列数据库操作的方法，让我们的注意力更关注于模型中。客户端通过查询方法，向仓储中请求对象，然后再返回用户所需的对象。

　　这段代码大概是这样的:

public interface IRepository<T> where T : EntityBase
{T GetById(int id);IEnumerable<T> List();IEnumerable<T> List(Expression<Func<T, bool>> predicate);  
    void Add(T entity);   
    void Delete(T entity);    void Edit(T entity);
}