サービスと言うと、ロギングやキャッシュなどのシステム・サービスを想像する方も多いかもしれませんが、Service Layser パターンの言うサービスは、アプリケーションがユーザーにどんな機能を提供するかを意味する、ドメイン・サービス寄りのものになります。
Table Module や Domain Model でビジネスロジックを記述すると、そのエントリポイントがいくつものクラスに分散するため、総じて、どんな機能がどれだけ提供されるのかが曖昧になります。ユーザー入力やイベントのハンドラといった、ソフトウェアシステムを組む層からそれらを利用するさい、いくつものオブジェクトを直接扱うロジックを書くのは、混乱のもとです。
複雑なオブジェクト群が結局どんな機能を提供するのかを、Service Layer に列挙し、システム側からはそこに見えるサービスを通してのみ、ビジネスロジックと連携するようにすると、うまく関心が分離できます。
各ビジネスロジックオブジェクトは、どこかで利用した処理を、別の箇所で再利用している場合もあります。データベースのトランザクション境界は、必ずしも、メソッドの先頭と末尾でないかもしれません。Service Layer が提供する粒度は、データベーストランザクションの範囲を決めるのにも役立ちます。Domain Model や Table Module には、begin/commit/rollback といった RDBMS の関心を含まず、Service Layer にトランザクション境界を隠蔽するのが良い策です。
トランザクションにかぎらず、同じ要領で、複数のオブジェクトの連携に必要な制御、入力の整合性チェックなど、特定のビジネスロジックには属さない、機能全体にまたがる雑用も隠蔽します。
Transaction Script は、ビジネスロジックのエントリポイントが明確で、多くの場合、手続き全体がアトミックなデータベーストランザクションになってきます。そうでない場合でも、直接的に SQL を意識して書いているコードであれば、トランザクションの制御のような制御も、(他のオブジェクトとの関係にまたがる事情がないので)直接書くのが理にかなっています。ビジネスロジックが Transaction Script や単純な単一テーブル CRUD でよい場合、Service Layser を挟む必然性はありません。