领域逻辑的组织分为三块：事务脚本、领域模型、表模块
一.事务脚本--面向过程的编程
过程描述：
从表现层获得输入、进行效验、将数据存储到数据库中以及调用其他系统的操作等。
然后该过程将更多的数据返回给表现层。
基本的组织方式是让每一个过程应对客户的可能做的一个动作。
而我们可以把这样的模式想象成一个动作或者业务事务的脚本。
事务脚本的优点：
1.大多数开发者都能理解的简单过程
2.能够与一个使用行数据入口或者表数据入口的简单数据源层很好的合作
这一点感觉应该是数据层以datarow或者dataset作为数据层的接口或者参数吧
3.设定事务边界的方法显而易见：一个事务始于脚本的打开，中午脚本的关闭。
事务脚本的缺点：
1.当领域逻辑很复杂性增加时，当若干个事务需要做相似的动作时，通常是多个事务脚本包含相似的代码。
虽然可以提取这些相类似的代码形成公共的事务脚本，但是这样使得应用程序变成一张极度复杂的网，没有清晰的结构。
而且在这个过程中，我们还需要去寻找这些公共的事务，这是个很繁琐的过程。
其实个人感觉这就是面向过程的编程吧
二.领域模型--面向对象的编程
领域模型的开销：
使用的复杂性和数据源层的复杂性。
三.表模块
表模块方式看起来和领域模型很相似，比如在一个销售系统中，他们都有合同、产品和收入确认表。
关键的区别在于领域模型对与每一个合同都有一个相应合同类实例，而表模块只有一个公共的合同类实例。
表模块设计与数据集一起工作。比如在一个处理合同的表模块中，客户首先对数据库进行查询以生成一个记录集，然后以记录集
为参数创建一个合同对象。然后客户调用合同对象的方法来完成各种操作。
表模块介于事务脚本和领域模型之间，它围绕表而非直接围绕过程来组织领域模型。
缺点：
无法使用比如继承、策略和其他面向对象的技术。
优点：
与其软件架构中已有部分的衔接。