为了的更好的理解DDD，我们先简单介绍下Transaction Script
Transaction Script模式遵循的是过程式开发风格而不是面向对象方法。通常，为每个业务事务创建一个单独的方法，并将它们组合起来放入某种静态管理程序或服务类。每个过程都包含了完成业务事务所需的所有业务逻辑，包括工作流、业务规则和数据库持久化验证检查。
由于Transaction Script的特征，分层的一般架构
Transaction Script模式的一个优势是它易于理解，很快就可以让团队新成员上手而不需要具有该模式的预备知识。当出现新需求时，很容易向该类中添加更多方法，而不用担心影响或破坏现有功能。
Transaction Script模式非常适于那些逻辑中只包含很少或不包含可能增长的功能集合的小型应用程序，以及有不熟悉面向对象编程概念的初级开发者的团队
1.DDD领域驱动设计
1.1.领域驱动设计的核心
软件的核心是为用户解决领域相关问题的能力。
1.2.分层
1.3.核心元素
- entity
一些对象主要不是由它们的属性定义的，而是通过标志进行区分的。比如一个人，不是通过身高、体重、肤色等属性定义的，一般我们使用身份证来标识。
- value object
很多对象没有概念上的标识，它们表述了一个事物的某种特征。比如颜色、温度、长短等。
- repository
我们可以通过对象之间的关联来找到对象，但当它处于生命周期的中间时，必须要有一个起点，以便从这个起点遍历到一个entity或value object。比如现在有订单id(123)，需要构建Order aggregate对象时，我们就可以通过repository来完成这个过程。
- service
有时，对象不是一个事物，而是某种操作。比如购买商品时的购买行为等。
- aggregate
aggregate就是一组相关对象的集合，我们把它作为数据修改的单元。每个aggregate都有一个根(root)和一个边界(boundary)。比如在下面的图片中，一共有四个aggregate，分别是Customer、Order、Product、Product Categories。
[图片上传失败...(image-13fbb0-1540213534191)]
- factory
在创建整个aggregate时，创建工作可能变得很复杂，比如上图中Order aggregate的创建。对于这类的创建动作，我们可以使用Factory模型。
1.3.1.factory与repository的区别
虽然factory与repository都是为了创建aggregate对象，但是两者的职责是有着非常明显的划分的，其中factory负责创建一个新的aggregate对象，而repository则是从已有的存储系统中重建aggregate对象。
1.3.2.是不是所有的entity都需要引入repository？
在使用ddd架构时，我们在引入repository时，非常容易犯的一个错误，就是为每个entity都引入repository。为什么会这么做呢？
因为在Transaction Script中，通常一个表，一个dao；所以我们在ddd中使用repository时，自然而然的为每个entity引入一个repository。
1.4.DDD不仅仅是分层
在使用ddd时，我们容易陷入一个误区，就是根据ddd引入了大量的分层代码。虽然我们的代码是根据ddd的分层方式去组织，但是实际的业务逻辑却以及使用Transaction Script的方式在处理。是什么原因导致导致的呢？
- 1.对ddd理解不够透彻
- 2.没有抓住核心的业务
- 3.Transaction Script的影响
在上面的几个因素中，只能通过不断的实践ddd项目，才能够获得深入的了解，并无什么银弹。
1.5.充血模型与贫血模型的区别
待补充...
