1, 事务脚本 vs. 领域模型（Transaction Script vs. Domain Model）
作者基于功能的复杂性来区分两种模式的使用时机，却忽略了另外一个因素：功能的增加
领域模型将功能和数据置于同一个对象中，当需要增加新的功能时，只能通过为对象增加新的方法来实现，这造成了对象接口的不稳定，并无法在没有源代码的情况下进行功能增加
而事务脚本则可以灵活的进行功能的扩展：增加一个Command Handler子类，配置到系统中即可，不需要改变对象接口，不需要修改源代码
进一步，可以使用Visitor模式将领域模型和事务脚本粘合起来：核心或常用功能用领域模型建模，可以使用子类化消除复杂的逻辑判断，而预留一个accept（visitor）接口来支持功能的扩展
总之，当数据变化不大，而功能经常增加时（不是同一个功能逻辑复杂性增加，而是新功能的增加），事务脚本配合Command模式理论上拥有更好的扩展性
2，表模块（Table Module）
是“管理者（Manager）”模式的变种，管理的不是通用的内存对象，而是“实际的或虚拟的表，及其中的行”，可用于隐藏数据层，甚至根据表之间的关系，可以建立一个Table Module的继承层次
3，服务层（Service Layer）
初看到名字时，还以为基本是和“Enterprise.Solution.Patterns.Using.Microsoft.Dot.NET”中的“Service Interface”类似的模式，细看之下，发现正是最近想求证的一个模式，因为在自己的项目中混合使用了事务脚本和领域模型（前面1，事务脚本 vs. 领域模型中提到的问题和最终的方案，正是目前自己项目中的问题和方案），一直感觉不是很纯粹的设计，现在发现，目前的设计基本类似Service layer，只需要再明确划分一下“领域逻辑”和“应用逻辑”即可
(to be continue...)