领域逻辑的组织模式

3 April, 2020

目前领域逻辑的组织模式分为三种，“事务脚本”，“领域模型” 以及 “表模块”。

事务脚本类似于面向过程编程，事务脚本有以下优点：

• 它是一种大多数软件工程师都能理解的简单过程模型。
• 它能和一个行数据入口或表数据入口简单的数据源很好的协作。
• 非常容易设定事务的边界。

一个组数据源操作便是一个独立的事务脚本。 当然事务脚本也存在很大的缺陷，当领域逻辑开始变得复杂时，这些缺点就开始暴露出来。 当几个事务要执行类似的逻辑时，通常几个脚本中会含有某些相同的代码。 通过将这些代码提取出来，来形成公共的子例程，来消除这种情况。 但是，很多时候消除副本会变得棘手，而检测副本则更困难，倒是消除副本后的程序反而比以前还要杂乱无章，难以维护。

复杂的领域逻辑，必然要引入对象，解决前面描述问题的面向对象方法就是领域模型。 一个内容管理系统会有用户，文章等类，进行鉴权，以及写入等逻辑均置于领域模型中。 因此，发布对象调用一次写入方法。 可能还会有其他例程来完成一些读取功能，但它其实都是调用领域模型中已有打方法实现的。

领域模型的控制不再是由一个过程来控制用户某一个动作的逻辑，而是由每个对象都承担一部分相关逻辑。

领域模型的开销来自于数据源的复杂度和使用上的复杂性，刚刚接触领域模型的人会需要时间来适应这种思维方式。一旦习惯了，你就会很爽！ 另一方面你需要将数据源映射到领域模型上，数据源越是复杂，领域模型的效果就越是显著。

上为事务脚本

上为领域模型

第三中为领域逻辑的组织模式为表模块，它处于事务脚本和领域模型的一个中间地带。 和领域模型最大的区别就是在表模块中一个表只对应一个实例，而领域模型一行数据便能对应一个实例。

表模块的优点在于可以很容易的和软件架构中已经存在的部分衔接，很多GUI应用都是假定将其与SQL查询结果的记录集结果协同工作的。表模块就工作在记录集之上。你可以很容易的使用。

抉择

别问，问就，直接使用领域模型。

接下来我稍微介绍一下目前各个框架/库在领域逻辑的组织模式上的选择（只列出我用）：

• PHP

  • PHP 原生 <事务脚本>
  • ThinkPHP <领域模型>
  • Laravel <领域模型>
  • YII <领域模型>

• Java

  • java.sql.* <事务脚本>
  • MyBatis <表模块>
  • JPA <领域模型>

• Go

  • gorm <表模块 | 领域模型> （这个比较神奇）

现在用表模块的人普遍比较多，我曾遇到好几个J2EE工程师都并不喜欢JPA的思维模式。