Domain Logic approaches

我会带着你远行 2022-01-07 05:23 187阅读 0赞

> **“**领域逻辑组织可以分为三种主要的模式：事务脚本（Transaction Script）、领域模型（Domain Model）和表模块（Table Module）**”**

# 事务脚本 Transaction Script #

> 使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。大多数应用都可以被看作是一系列事务。一个事务可能将某种信息看作是以特定方式组织的，然后另一事务则会改变它。在客户系统和服务器系统这间的每次交互都包含一定数量的逻辑。它可能如显示数据库中的信息那般简单。蛤在其他一些情况下，它可能涉及许多校验和计算的步骤。事务脚本将所有这些逻辑组成成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封装器。每个事务都有自己的事务脚本，尽管事务间的公共子任务可以被分解成多个子程序。

事务脚本组织成类的方法

将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。（最常用）

每一个事务脚本对应一个类，此时需使用命令（Command）模式。

## 使用时机 ##

** **

**务脚本胜在简单。**对于只有少量逻辑的应用程序来说，使用这一模式非常自然，无论在性能上还是理解上都不会带来太大开销。

当业务逻辑越来越复杂时，该模式就会越来越难以保持良好的设计。它特有的问题是事务之间的冗余代码。

# 领域模型 Domain Model #

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

> 面向对象的领域模型通常看起来与数据库模型类似，但仍有许多不同之处。领域模型混合数据和处理过程，拥有多值和复杂的的关联网，并且使用继承。

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

由于业务行为是经常变化的。因此易于修改、建造和测试对领域层来说十分重要。因而，领域模型与系统中的其他层之间的耦合度应达到最小。许多的分层 模式，它们的主导思想就是领域模型与系统中其他部分间保持尽可能小的依赖