4，领域逻辑模式

事务脚本-----------
使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。
运行机制
使用事务脚本时，领域逻辑主要通过系统所执行的事务来组织，例如：如果需要预定一间酒店房间，则在“预定酒店房间”这一过程中会发现用于查找空房间，
计算价格和更新数据库的逻辑。
这种方法的好处之一就是你无须关系其他事务的内部实现，你的任务就是获得输入，查询数据库，处理并将结果保存到数据库中。
一般情况下，竟可能分离事务脚本，至少应当将他们放在不同的子程序中，而更好的方法则是将他们置于与其他处理表现层和数据源层的类相独立的类中，
此外，绝不让事务脚本调用任何表现层逻辑。

可以用俩种方法来把事务脚本组织成类，最常用的方法是讲数个事务脚本放在一个类中，每个类围绕一个主题讲相关的事务脚本组织在一起，
另一种方法则是每个事务脚本对应一个类，如下图，（此时需要使用命令行（command）模式）。这种情况下应定义一个所有命令的父类，在父类中声明事务脚本
逻辑适合的执行方法，
优点在与：允许你运行时以对象的方式来操控脚本类的实例。


 

使用时机
事务脚本胜在简单，对于只有少量逻辑的应用程序来说，使用这一模式非常自然，无论在性能上还是理解上都不会带来太大的开销，
但是，当业务逻辑越来越负责时，使用这一模式就会越来越难以保持良好的设计，他特有的问题是事务之间的多余的代码，既然主要是为了处理一个事务，那么任何公共
代码都可能存在多个副本。

收入确认问题---------------------
收入确认是商业系统中一个常见的问题，关心的是何时讲所收的钱入账，如果我卖给你一杯咖啡，收入确认就很简单了，我给你咖啡，收钱，然后立即将钱入账，但是许多交易中
的收入确认却很负责，例如：你给我一笔预聘费，让我为你提供一年的顾问服务，即使你今天就给了我这笔钱，我可能仍然不能立即入账，因为完成服务需要一年时间，可能一个月
以后你意识到作为写作的我的编程技术退化了，于是取消这以合同，解决办法就是没月讲预聘费1/12入账。

收入确认的规则种类繁多而且异变，这些规则有的是由法律决定，有的是由行规决定，有的是由公司的经营政策决定，收入跟踪变成了一个十分负责的问题。
 领域模型-----

 在应用程序中使用领域模型需要建立一个完整的由对象组成的层，来对目标业务领域建模，你会发现其中有的对象模拟业务活动中的数据，有的对象捕捉业务使用的规则，数据和处理
 一般整合在一起，从而使得数据和数据之上的操作紧密聚合。

 因此，领域模型衍生出俩种风格，简单领域模型看起来与数据库设计很类似，这种设计中几乎每一个数据库表都与一个领域对象对应，而复杂领域模型则与数据库设计不同，他使用继承
 ，策略和其他设计模式，是一张由互联的细粒度的对象组成的复杂网络，复杂领域模型更适合于复杂的逻辑，但它到数据库的映射比较困难。