什么是事务脚本模式

事务脚本模式(Transaction Script)可以简称 TS 模式，这个模式本身的核心思想就是名称中的两个词，即：事务与脚本。事务可以理解为实际需要执行的一段原子业务；脚本则是指的一组原子业务的编排方式。而通常来说脚本的编排会直接映射到用户的一个行为动作上。

事务脚本本身可以理解是用户动作的一次任务编排，而触发的方式一般直接与用户的行为建立联系。

由于使用的是脚本的编排方式，所以事务的组织是面向过程的。

而对于事务脚本模式，不同关联用户动作的脚本所编排的事务之间一般是相互隔离的，即事务之间不会影响。但不同的脚本之间可以编排相同的事务，即事务之间可以复用。

事务脚本模式的实现

或许经过了 MVC 洗礼的开发们就会突然发现，我平时写的这个不就是食物脚本吗？其实是这样的，事务脚本模式的本质是事务与事务的编排。一次用户的动作对应的是一次业务请求。请求后便需要一层来进行事务的编排，也就是脚本层。脚本层是对于事务本身的编排，所以我们还需要一层事务层。事务针对的是数据库的多次操作，所以还有一层数据库层。

于是我们有了：脚本层、事务层、数据库层的三层模型。而这与经典的三层模型是等价的，当然如果你的框架结构中有 Handler 层或者 Manager 层的话，脚本层或者事务层的对应关系是可以进行调整的。

而对于事务脚本的实现模式上就可以发现，按照事务脚本模式设计的话，其中是完全不需要任何面向对象的设计模式。所以在进行事务脚本设计模式建模的时候，其中的任何逻辑都可以通过 if、for、while 等元素表达。

事务脚本的优点

首先，事务脚本中的脚本编排是根据用户行为进行的，并且在进行设计建模的时候只使用流程控制元素进行。这使得事务脚本可以直接映射到业务流程上，对于业务的流程来说有极高的可解释性，而这对于持续优化用户体验来说是非常重要的。

其次是实现简单。事务脚本模式由于是面向步骤编程，过程描述方式符合一般认知步骤。在进行建模设计的时候往往可以快速进行设计并完成组织。学习曲线十分低，并且在加入了单测等业务边界约束后进行开发的业务入门门槛极低。而同时由于时间简单，事务脚本模式的代码质量标准较好把控。

最后是事务脚本模型不需要前置领域知识。由于仅针对业务流程编排事务，所以并不需要完整的领域知识。例如先按照查询和命令对用户动作进行一次划分，然后针对业务属性较为多的部分进行着重建模。特别的，尽管不满足领域的设计条件，但是当数据库是按照领域模型的模式进行设计的时候，我们仍然可以称其为领域模型，虽然它实际上是一个贫血模型。，

事务脚本的缺点

对于这种模式的缺点，想必每一个进行过系统重构的人都会有感受。事务脚本的核心问题主要有两方面。

一方面是事务脚本模型由于是通过步骤脚本对事务进行的编排，而其中并不是进行的领域相关的设计。所以当业务扩张脚本数量变多的时候，对应的事务本身也会爆炸式的增长（往往无法进行合理的利用）。

同时，由于事务的步骤脚本本身具有上下文关系，所以他有面向过程编程相同的缺点：扩展性很低。当业务逐渐膨胀的时候，在对不同的事务进行业务调整的时候，由于事务之间未进行领域抽取与聚合，所以需要调整的内容可能会分布在内容的各个角落。

什么时候使用？

什么时候可以使用事务脚本模式呢？我可以结合上面的优点和缺点给出以下两种情况。

第一种是当不满足领域模型设计条件的时候。不论是由于技能原因，还是由于缺少领域专家，当进行系统设计时的背景无法满足领域建模的时候，就可以使用事务脚本模式设计。这种情况往往是进行新的业务尝试，业务的领域属性并不明确，或者是无法明确抽象。那这种情况下可以先进行事务脚本模式的编写。

第二种是项目足够单一的时候。这里的单一为业务单一、职责单一、变动单一。可以理解成当用户动作只有少量的时候，那么此时对动作的抽象成本较高。同样的当项目职责单一，又不便于直接划归为某一子领域的时候，进行领域建模无意义。而当变动频率低程度小的时候，事务中方法的膨胀速度也就比较缓慢。

总的来说，当项目起步、或者业务还在朦胧地试错期的时候，可以直接进行事务脚本模式的编写。

但要注意的是，要时刻警惕事务爆炸，当业务已经明确或可以领域知识足够后，就要考虑将事务合并抽取领域模型了。

最后

事务脚本模式长久不衰的原因正是因为它足够简单。同时这让它是最可靠的实现统一代码规范的模式，因为入门门槛足够低，即便不熟悉的人也可以快速上手。而事务脚本模式的基础上也可以对事务进行封装，例如使用策略模式、命令模式等结合使用对事务进行抽象。在实际开发的时候，也可以单独地将业务层抽离出来通过事务脚本的方式进行业务的调度编排，而在下游领域服务中再进行领域建模设计。

最后，我们不应因为它足够简单而感到不好意思使用，而是应该在业务足够简单清晰的时候选择最合适的事务脚本模式。