组织域逻辑

在组织域逻辑过程中我将它分成了三个主要模式：Transaction Script，Domain Model和Table Module。

存储域逻辑的最简单的方法是Transaction Script。一个Transation Script是本质是一个过程，它从表现取得输入，通过校验和计算的处理，并将数据存储到数据库的，调用其它系统的任何操作，向表现回馈更多的数据，可能进行更多的计算，以帮助组织和格式化回馈的数据。基本的组织方式是为用户可能会想要做的每一个行为创建一个独立的过程。因此，我们可以把它当作是一个行为或业务过程的脚本。它不需要是一个代码的内联过程，分散到子过程中的片段，这些子过程可以由不同的Transaction Script共享，但是主要驱动力还是每个行为的过程。所以一个零售系统可能相关的Transaction Script用于结账，向购物篮加入一些东西，显示交货状态，等等。

Transaction Script的益处包括：

• 它一个大多数开发者都能理解的过程模型。
• 它与简单的使用Row Data Gateway或Table Data Gateway数据层一起工作得很好。
• 界定事务的界限非常明显：开始于事务的打开，结束于它的关闭。很容易使用工具去做这件事。

它也缺点，这些缺点在业务逻辑的复杂度增加时会显得更加明显。通常在完成相同的功能的事务中会出现重复代码。这个问题可以通过重构，抽出通用子过程，但是即使这样，还是有很多重复很难移除。这会导致应用程序最终成为一个没有清晰结构的过程的混乱的web。

对于复杂的逻辑是对象发挥作用的地方，处理这人问题的面向对象的方法就是Domain Model。对于一个域模型主要的组织方式就是创建一个我们域的模型，这个模型主要根据域中的名词进行组织。因此，一个租借系统可能会有租约、资产等类。处理验证和计算的逻辑会放入这个域模型中。一个船运对象可能包含计算运输费用的逻辑。它也有可能计算票据的过程，但是这个过程必须委托给域模型中一个方法。

相对于Transaction Script使用Domain Model，其实也就是人们说的很多的了面向对象的例子。每个对象都持有与其相关的一部分逻辑，而不是将一个用户操作的所有逻辑都放在一个过程中。

想要使用一个简单的例子抓住它们的本质区别是很困难的，但在对模式的讨论中，我会试图通过以两种方式创建一个简单的域逻辑来演示它们之间的本质区别。发现不同的最简单的区别就是通过查看两种方法的序列图。根本的问题是不同的产品根据一定给定的合同有不同的收入确认算法。计算方法必须判断产品的种类，应用正确的方法，然后创建收入确认对象获取计算的结果。

（未完）