Table Module は、データベーステーブルひとつにつき、その操作を担うオブジェクトをひとつ設けることで、Transaction Script がどこで何を行うかわからない状況を、少し緩和するアイデアです。このアプローチは、長大化してしまった Transaction Script の当座のリファクタリングに、とても向いています。
Table Module として部分に分割されたビジネスロジックは、実行の結果影響を及ぼす範囲がひとつのテーブルに限定されるので、Transaction Script よりも小さな粒度で動作を確認できます。部分的な動作テストであれば、テスト用データベースも、限られたテーブルの準備だけで済むようになります。
しかし、Domain Model ほどの自由度はありません。データベースの構造に縛られず、複雑な問題をどのように抽象化して解決してもかまわないのが、Domain Model のメリットです。Table Module によって得られる秩序は、逆に、設計にデータベースの物理的な構造からの制約を受けることになります。
Domain Model はデータベース構造に縛られない、プログラミングの世界で問題を考える方法です。なので、純粋なロジックをいくらでも切り出すことができます。データベースを必要としない単体テストによって、かなり広範囲にモデルの信頼性を確保できるのも、Table Module や Transaction Script にない、Domain Model のメリットです。
しかし、より重要なのは適材適所です。せいぜい 2 つか 3 つほどのテーブルに対して、比較的簡単な操作を行うだけでよい場合、ある程度の秩序を保ちつつ、コードから直接的に SQL を意識できる Table Module が、ちょうどいい選択になってくるかもしれません。