“领域逻辑组织可以分为三种主要的模式：事务脚本（Transaction Script）、领域模型（Domain Model）和表模块（Table Module）”
事务脚本 Transaction Script
事务脚本组织成类的方法
将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。（最常用）
每一个事务脚本对应一个类，此时需使用命令（Command）模式。
使用时机
事务脚本胜在简单。 对于只有少量逻辑的应用程序来说，使用这一模式非常自然，无论在性能上还是理解上都不会带来太大开销。
当业务逻辑越来越复杂时，该模式就会越来越难以保持良好的设计。它特有的问题是事务之间的冗余代码。
领域模型 Domain Model)
由于业务行为是经常变化的。因此易于修改、建造和测试对领域层来说十分重要。因而，领域模型与系统中的其他层之间的耦合度应达到最小。许多的分层 模式，它们的主导思想就是领域模型与系统中其他部分间保持尽可能小的依赖
使用时机
何时使用这一模型完全取决于系统中的行为复杂程度。如果你的业务规则复杂多变，涉及检验、计算、衍生，你就应该利用对象模型进行处理， 反之，如果你只有一些简单的判空值和少量的求和计算，事务脚本是一个更佳的选择。
影响选择的因素之一是开发小组灵活运用领域对象的程度。学会如何使用领域模型是极为重要的，故而出现了许多”理论体系迁移？"方面的文章，它们都是关于 对象使用的。要熟悉领域模型需要实践和训练，但是一旦掌握了它，我发现处理解决最简单的问题外，很少会有人再使用事务脚本。
使用领域模型时，你可能会考虑设立一个服务层，以便给领域模型一个更清晰的API。
表模块 Table Module
使用时机
最常使用这一模式的场合是在Microsoft的COM设计方案中。在COM（及.net)中，记录集是应用程序的主要数据仓库。ADO 库提供了良好的机制，可供你以记录集的方式来 存取关系数据库中的数据。
代码示例：https://github.com/tianyaxiang/ApplicationArchitecture
本文首发于个人微信公众号：webguan ；欢迎您的关注