Transaction Script(事务脚本):
使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。对于很对业务应用来说都可以被看作是一系列事务。业务的一个请求将触发一系列的业务处理逻辑，而我们在代码中通常采用SpringAOP声明式事务方式将事务控制在业务层的实现类的方法上面，一个请求对应一套业务流程，对应一个事务控制。前面我们也提到了事物的4个特性中，有一个隔离性表示事务与事务间是相互隔离的，互不影响的。
事务脚本将所有这些业务逻辑组织成单个过程，在组织时通常都是考虑的业务逻辑的过程，将业务逻辑按照一定的顺序排列执行，然后将事务控制在某一个主方法的入口上，并且在过程中直接调用数据库，或者调用数据库封装器（如MyBatis、Hibernate等ORM映射框架）。每个事物都有属于它自己的事物脚本，这里的脚本指的是方法。
事务脚本比较适合于业务逻辑相对简单的情况下，理论上来说，事务控制在3层架构中任何一层都是可以的，但是我们通常来说，都是控制在业务层的实现上的。事务脚本是属于领域逻辑模式中一种，将其置于与其他处理表现层和数据源层的类相对独立的类中。如果置于数据源层的类中，会失去事务脚本的控制原则，因为可能只控制了一部分业务逻辑，而其他的业务逻辑并没有控制到。
对于事务脚本来说，很多时候都有3个具体的类来构成，他们一般分别是Sevice,Dao,JavaBean, Service类主要用于组织业务逻辑，Dao类主要用于实现数据的存储，JavaBean主要用于数据的封装。
事务脚本贵在简单，对于少量逻辑的应用程序来说，它非常实用 。如果业务逻辑复杂时，就会导致事务之间的冗余代
Domain Model(域模型):
领域模型同时将行为和数据作为领域逻辑的核心。因此无法像事务脚本一样只关心过程和表面需求，也无法像表模块一样只关心数据。问题终于清晰了：
（1）事务脚本模式不（或逃避）深入分析需求。
（2）表模块强调了数据，得不到充分的领域模型。
（3）领域模型模式采用通用语言解决需求问题，采用过程和数据结合解决领域逻辑的组织。
实在是不能说的再复杂了，因为本质上的简单。由于领域逻辑本身的特性，往往会产生以下两种倾向的领域模型：
（1）形式上类似事务脚本模式的领域模型，这是由于领域逻辑本身的特性决定，即使从代码上看起来十分相似，但是具有更稳定和更少需求变动的优势。
（2）形式上类似表模块模式的领域模型。其他同上。
优势也是实在太明显了。我实在不能拒绝。这不是技术上的问题，这是需求分析和模型设计上的问题，我实在不能把这些简单的概念搞的更复杂了。在使用和不断完善通用语言的需求分析过程中，通过多次深入分析和迭代我们得到了比较稳定的需求分析，在完善设计的过程中，我们通过使用和识别出实体、值对象、领域服务和领域事件等概念，划分出聚合、子域、界限上下文来简化我们的设计。这是在以领域逻辑为核心的前提下，不断深入、细化和迭代的自然结果。
Table Module(表模块 ):
表模块不再将过程作为组织领域逻辑的核心，而是将数据作为领域逻辑的核心。一些在深受事务脚本模式的毒害的团队可能意识到了过程的变化太不可预测了，而往往又不去或不能在需求分析上下功夫，因此从技术角度抓住了业务逻辑中相对过程更稳定的数据部分。也仅此而已。采用表模块的模式往往有以下两个结果：
（1）设计的结果主要是E-R图或披着类图皮的E-R图。
（2）自然的采用数据模型但坚持认为是领域模型。
也自然而然的得到表模块的适用范围：
（1）业务逻辑本身就是以数据为核心的简单处理。
（2）业务逻辑的流程十分简单，这点和事务脚本是一致的。