什么是领域驱动呢？
这里Martin Folwer提出的三种模式：
事务脚本 Transaction Script
领域模型 Domain Model
表模块 Table Module
虽说马丁大叔有些言论值得商榷，但关于这三种模式的归纳我认为在近几年内还是非常到位的。关于这三种模型的详细内容，可以参考马丁大叔的那本《企业架构模式设计》。我只为了方便说明稍微带上一些。
这三种模式的分类标准，应该是按照系统中业务逻辑的组织形式来划分的。
简单地说，如果你把所有的业务逻辑归纳起来，成为一个个“函数”，应该很容易理解，就好象当初学习C语言的时候老是让我们写函数一样。把这些函数以存储过程或其他形式存放在数据库里，然后在程序中直接调用，这便是是“事务脚本”。注明的是，这和所谓的“三层架构”无关，就好象Petshop里那样虽然没有使用存储过程，但是把那些函数以一个个函数调用的形式写在了DAL中，仍然属于“事务脚本”，用一些人的话说叫“不OO”。
“事务脚本”这种方式简单易懂，问题主要在于系统在变的庞大后对于一堆堆的函数的维护成了问题。于是便有了大名鼎鼎的“领域模型”。简单地说，领域模型希望完全脱离数据库的限制，让程序员进入一个彻底的面向对象的世界，以面向对象的方式，运用各种复杂的设计模式，获得一个复杂的面向对象的体系。我们用这种方法来描述业务逻辑。而这样设计的问题在于数据库大多不是面向对象的，因此我们需要通过某种方式保存（“行话”叫“持久化”）这个面向对象的体系中的数据（这里埋下伏笔，这个“保存数据”的内容就是和EDM大显身手地方）。
而“表模块”显然“很net”。我认为这种模式大体上是一种领域模型的妥协，可能马丁大叔对这种模型的归纳也就来自ado.net中的的Dataset。“表模块”中程序员使用面向对象的方式来进行业务逻辑的设计的，但是在设计中，必须用到一种“表对象”（其实就是DataTable了），这实质上是数据库中数据表的映射，程序员只需要在表对象上进行数据的修改，然后通过一些方式这些数据就能自动的更新到数据库中去。也许是ado.net提供的强大功能将“表模块”支持的太完美了，以至于在.net平台下的开发很多人都不知不觉使用了“表模块”这种模型。
而DDD，简单地说就是在领域模型中，先设计领域模型再有数据库，于是叫领域驱动，相反地，对于某些业务逻辑简单的系统，可以先有数据库再有领域逻辑，也就是数据驱动了。