2.1 抉择

那么，这三种模式应该怎样选择呢？要做出抉择并不容易，在很大程度上取决于领域逻辑的复杂度。图2-4是一个用PowerPoint示意的不精确图表，它能指导你进行选择。虽然我并不欣赏这种非量化的表示方法，但它有助于可视化我对这三种模式区别的理解。当领域逻辑很简单时，领域模型并不合适，因为要透彻理解这一模式需要很大代价，而且数据源层的复杂性也会在开发中增加许多工作量，这些努力此时不会得到回报。然而，当领域逻辑的复杂度增加时，除领域模型以外的其他方法就都不再适用，因为它们增加新功能的困难程度会随系统复杂度的增加而呈指数增长。

图2-4 对不同的领域逻辑组织方式，领域逻辑的复杂度和工作量之间的关系示意

当然，你的问题是要确定应用在横轴的哪个位置。好消息是只要你的领域逻辑复杂度大于7.42，你就应当使用领域模型。坏消息是没有人知道如何测定领域逻辑的复杂度。因此，事实上你所能做的只是向那些有经验的开发者请教，他们能对需求进行早期分析并做出正确的判断。

某些因素会对图中的曲线做一些修正。一个熟悉领域模型的开发小组能降低使用这一模式的固有开销，但由于数据源层的复杂性，它不会降低到与其他模式相同的起点。但是，开发小组的经验越丰富，我越倾向于使用领域模型。

是否应用表模块很大程度上取决于环境对通用记录集结构的支持。如果开发环境拥有大量基于记录集的工具（如.NET或Visual Studio），则表模块就很有吸引力。事实上，我找不出在.NET环境下使用事务脚本的理由。当然，如果没有特定的基于记录集的工具，我就不会纠缠于表模块。

一旦你做出了抉择，虽然你的决定不是绝对不可更改的，但中途的改变也会很棘手。因此，事先花费一些时间来进行思考和选择是值得的。如果在开发过程中才发现你的选择是错误的，且你原来的选择是事务脚本，那么不要犹豫，你应立即改用领域模型。而如果你原来的模式是领域模型，中途转而采用事务脚本，这通常不太值得，除非能简化你的数据源层。

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