领域逻辑组织可以分为三种主要的模式：事务脚本(Transaction Script)、领域模型(Domain Model)和表模块(Table Module)。
我们用得最多就是事务脚本方式（像微软的Petshop4.0,很多国内的三层结构代码生成工具生成的系统，而且这种方式很多公司，很多企业级的项目都在用，还有一些框架引导你用这种方式实现)。这种方式最大的特点就是：简单实用。
-
事务脚本
使用流程来组织业务逻辑，每个流程处理来自表示层的单个请求。大多数应用程序可被视为一系列事务。交易可以将某种信息视为以特定方式组织，然后另一种交易将改变它。客户端系统和服务器系统之间的每次交互都包含一定量的逻辑。它可能与在数据库中显示信息一样简单。在其他情况下，它可能涉及校验和计算中的许多步骤。事务脚本将所有这些逻辑组合到一个进程中，直接在进程中调用数据库，或者只传递一个简单的数据库包装器。每个事务都有自己的事务脚本，尽管事务之间的常见子任务可以分解为多个子例程。
事务脚本组织成类
将多个事务脚本放在一个类中，每个类围绕一个主题组织相关的事务脚本。 （最常被使用）
每个事务脚本对应一个类，您需要使用命令模式。
何时使用
脚本获胜很简单。对于具有少量逻辑的应用程序，使用此模式是很自然的，并且在性能或理解方面没有任何开销。
随着业务逻辑变得越来越复杂，维护良好设计变得越来越困难。它的独特问题是交易之间的冗余代码。
-
领域模型
一种对象模型，它结合了行为和数据的字段。在应用程序中使用域模型需要构建完整的对象层以对目标业务域建模。您会发现某些对象模拟业务活动中的数据，而某些对象捕获业务使用的规则。通常集成数据和处理，以便对数据和数据的操作进行紧密聚合。
面向对象的域模型通常看起来类似于数据库模型，但仍然存在许多差异。域模型混合了数据和流程，具有多值和复杂的关联，并使用继承。
域模型派生出两种样式。简单域模型看起来非常类似于数据库设计，其中几乎每个数据库表都对应于域对象。复杂域模型与数据库设计不同。它使用继承，策略和其他设计模式。它是由互连的细粒度对象组成的复杂网络。复杂域模型更适合复杂逻辑，但它在数据库中。映射很困难。
因为商业行为在不断变化。因此，很容易修改，构建和测试域层。因此，域模型与系统中其他层之间的耦合程度应该是最小的。许多分层模型，它们的主导思想是使域模型在系统的其余部分之间保持尽可能小。
何时使用
何时使用此模型完全取决于系统中行为的复杂性。如果业务规则复杂且可变，涉及检查，计算和派生，则应使用对象模型进行处理。相反，如果您只有一些简单的空值和少量的求和计算，那么事务脚本就更好了。选择。
影响选择的因素之一是开发团队可以灵活使用域对象的程度。学习如何使用领域模型是非常重要的，所以有很多关于“理论系统的迁移？”的文章，这些都是关于对象的使用。熟悉领域模型需要实践和培训，但是一旦掌握了它，我发现除了解决最简单的问题之外，很少有人使用事务脚本。
使用域模型时，您可以考虑设置服务层，以便为域模型提供更清晰的API。
-
表模块
表模块将域逻辑组织在与数据库中的表对应的类中，并使用单个类实例来包含将执行数据的程序。
何时使用
此模式最常见的用途是Microsoft的COM设计。在COM（和.net）中，记录集是应用程序的主要数据仓库。 ADO库提供了一种很好的机制，可以将关系数据库中的数据作为记录集进行访问。
|
实现方式 |
优点 |
缺点 |
备注 |
|
事务脚本 |
|
|
像Petshop4.0、国内很多三层架构代码生成工具生成的系统以及现今国内绝大部分企业级系统(本人估计)都采用这种方式 |
|
领域模型 |
1． 采面向对象方法直接对系统的问题域进行分析或建模，领域模型直观地反映现实世界，能够更好用面向对象语言模型转换，是一种纯OO模型 2． 能够解决很复杂的业务逻辑 3． 可以有效地利用面向对象的特性（抽象，封装，继承、多态等）与相关技术（如设计模式，重构等），以提高系统的可扩展性与复用性。 |
|
现在很多企业级应用项目开始采用此方式，这主要得益于ORM框架不断成熟，以及模式运动，同时一些设计原则也比较好解决相应问题。 请参看参考书目的： 11、13、16、6、2、5
|
|
表模块 |
1． 适合于系统业务较直观，CRUD操作比较集中 2． 如果支持平台中有比较好工具集支持(如：Ado.Net，数据控件之类)，开发速度快，效率高 |
1．当业务并非CRUD集中型操作，特别是领域模型和数据库表模型差异较大时，难度非常大，因此不适合业务复杂的系统 |
在Microsoft .Net平台有很多工具集支持，有时候你甚至不需写一行代码就可以实现CRUD操作 |