事务脚本与领域模型

最近看了下《企业应用架构模式》，里面提到了事务脚本跟领域模型两种建模方式，作者比较推崇领域模型，认为在复杂业务下面可扩展与可维护性更好。但是在实际工作中其实并没有特别的体会，并且之前一直使用的都是类似事务脚本的方式，比较简单易懂，不需要太多思维转换与跳跃。

下面就列举一下工作中使用两种方式架构对比下，体验下两者的差异。

事务脚本

顾名思义，事务脚本即将每个用例作为一个脚本，使用数据库编排的方式实现，之前有一个操作余额的项目，基本功能包括创建账户，支付，提现等操作，使用的就是事务脚本，个人觉得代码质量还不错，是工作中少有的比较有成就感的项目。

下图是创建账户的操作

下图是支付的操作

代码包结构

整体结构

其中命令层使用的数据模型都是直接来自DB层的DO（dataobject），不过在DO中添加了一些业务语义，例如增加余额等方法。整个结构很清晰，没有增加一些额外的实体（与数据库一一对应，而且与业务模型对应），理解成本低，基本直接线性阅读就可以理解。由于这个项目偏底层一些，属于比较稳定的基础设施，后续需求非常少，因此扩展性与维护性没有实际校验。

领域模型

现在集团都在推行领域模型，基本到了全民领域模型的地步了，下面就对团队负责的支付平台为例，看看使用了领域模型的应用一次调用过程。

其中至少涉及到了两次的模型转换，而且这些模型转换之间往往一直都是同步变更的，这样在修改一个模型时往往需要修改多个类，并非起到了隔离变化的作用。

使用领域模型的一个优势是可以将业务逻辑收敛（通常被认为是稳定的逻辑，更准确应该叫确认性的逻辑，因为业务会变化），但是其实事务脚本的模型也可以实现类似的逻辑，不过不可否认，当业务模型的关系变得复杂的时候，如果还是将数据层DO与业务逻辑放在一起会增加复杂性。

总结

其实无论是事务脚本还是领域模型也好，只要可以降低系统的复杂度，增加系统的可读，可扩展，可维护性就可以，当系统业务逻辑并不是很复杂，使用事务脚本成本更低，而且可读性更好。使用一层领域模型还增加一些额外成本，尤其是各个域都想着通过SPI的方式隔离变化，这样会导致模型越来越多，而且之间的转换也很多。关于架构与设计的方法论很多，但是需要结合实践来看，做到真正的可落地有实效的方法。