读《企业应用架构模式》第二章 组织领域逻辑

-------------前面在于整理的过程中，发现仍然有少部分地方，欠缺理解，希望后续可以顿悟。但大体的东西对于我来说确实是帮助甚大---------------

今天主要整理第二章，组织领域逻辑，领域逻辑也可以理解为业务逻辑。相信换个说法，就好理解了。

组织领域逻辑：

领域逻辑的组织可以为三种主要的模式：事务脚本模式、领域模型模式以及表模式。

    保存领域逻辑最简单的方法是使用事务脚本。简单地说，事务脚本是一个面向过程的模式。可以这样理解，从表现层获得输入--->进行校验和计算结果--->将数据存储到数据库中，以及调用其他系统的操作等。然后，该过程将更多的数据返回给表现层，中间可能要进行大量的计算来组织和整理返回值。基本的组织方式是让每个过程对于用于可能做的一个动作。

   我们可以将以上模式想象成一个动作或业务事务的脚本。该脚本不必一定是单个的内嵌过程，还可以分离成不同的子例程，这些子例程可以在不同的事务脚本之间共享。但是，每一个动作还是由一个过程来驱动。例如，一个零售系统可能会有结账，将商品放入购物车，显示交货状态以及其他一些事务脚本。

事务脚本的优点：

1、它是一个大多数开发者都能理解的简单过程模式。

2、它能够与一个使用行数据入口或表数据入口的简单数据源层很好的协作。

3、设定事务边界的方法显而易见：一个事务始于其脚本的打开，终于其脚本的关闭。很容易使用一些工具在幕后设定事务边界。

   但是，事务脚本也存在许多缺点，当领域逻辑的复杂性增加时，缺点就会凸显。当若干个事务需要相似的动作时，通常使多个脚本中包含某些相同的代码。通过将这些代码提取出来组织成公共的子例程可以部分消除这种情况，但在许多时候，消除副本仍比较棘手，而检测副本则更为困难。这使得应用程序没有清晰的结构，变成了一张由许多程序组成的极度杂乱无章的网（蓝色仍需理解）。

领域模型的介绍：

   当然，复杂逻辑的处理，必然要引入对象，解决前述问题的面向对象方法就是使用领域模型。一个应用领域的模型，至少在开始的时候主要围绕领域中的名词来组织。

用领域模型而不是事务脚本正是面向对象的“理论体系转换”的精髓。在领域模型中，不再是由一个过程来控制用户某一动作的逻辑，而是由每一个对象都承担一部分相关逻辑。

   领域模型的开销来自使用上的复杂性和数据源层的复杂性。

表模型模式：

   表模式粗略看起来是领域模式很相似，但是两者之间是有区别的，关键的区别在于领域模型对数据库中每个合同都有一个相应合同类的实例，而表模式只有一个公共的合同类实例。表模式设计成与记录集一起工作。因此，在一个用于处理合同的表模块中，客户需要首先对数据库进行查询以生成一个记录集（按照我的理解，这里的记录集，应该是返回结果集）。然后以记录集为参数创建一个合同对象。客户可以调用合同对象的方法来完成各种操作。如果客户要对某个指定的合同进行操作，它就必须在调用方法时附加该合同的ID。

    表模块是事务脚本与领域模型的一个中间地带，它围绕表而不是直接围绕过程来组织领域逻辑，提供了更多的结构，很容易发现和移除冗余代码。但是可能无法使用许多在领域模型中可以使用的组织细粒度逻辑结构的技术，如继承，策略和其他面向对象的设计模式。

那么如何在企业应用开发中抉择：

    很大程度上取决于领域逻辑的复杂性。在领域逻辑很简单时，领域模型并不合适，因为要透彻理解这一模式需要很大代价，而且数据源层的复杂性也会在开发中增加许多工作量。然而，当领域逻辑的复杂度增加时，除领域模型以外的其他方法就都不再适合，因为它们增加新功能的困难程度会随着系统复杂度的增加而呈指数增长。

    事先花费一些时间来进行思考和选择在开发中到底选择哪种模式是值得的。如果在开发过程中才发现你的选择是错误的，且你原来的选择是事务脚本，那么就直接改用领域模型。而如果你原来的模式是领域模型，中途向事务脚本转换，这就没必要了，除非你可以简化你的数据源层。

    其实三种模式间并不互相排斥，事实上，使用事务脚本处理一部分领域逻辑，同时采用表模式或领域模型来处理剩下的部分，这也是很常见的。