Transaction Script(Domain Logic Patterns)

Domain Logic Patternsは、ドメインロジック－よくビジネスロジックとか言われているもの－をどのように構成・配置するかについてのパターン。

概要

• プレゼンテーション層からのリクエストを、ひとつのProcedureとしてまとめる形でドメインロジックを構成するパターン。

メリット

• シンプルさ！
-> 理解しやすい。
-> メンテナンスしやすい。

• 他のトランザクション（nearly equal ドメインロジック）のことを気にしなくていい。
-> 多人数の並列開発に向いている。
-> スキルが低い開発者による低品質なコードの影響を局所化できる。

デメリット

• 同じようなコードがあちこちに出てきやすい。
• 結果的に、規模が大きくなりやすい。

注意

• 1メソッド・1クラスとして構成する必要があるわけではなく、必要に応じて構造化する（当たり前）。間違っても常に1メソッドとして作ったりしないこと。
• レイヤ構造とは独立。上記と関連するが、プレゼンテーションやデータソースとは切り離した方が良い。

バリエーション
Transaction Scriptのクラス構成
もっとも一般的なのは、いくつかのTransaction Scriptを1つのクラスとして構成する方法。ここで作成したTransaction Scriptクラスは、サブジェクトエリアとなる、らしい。サブジェクトエリアって何だ…。ユースケースとか、業務区分みたいなのかな。個人的には、ユー スケースごとにTransaction Scriptクラスを作っていることが多い。Fowlerの見解によると、「たいていの場合はこのアプローチがベスト」らしい。

Transaction ScriptをCommand[GoF]として作成し、Transaction Scriptごとに1クラスを作成する方法もある。自社の社内標準はこちらをすすめていて、この構造でないとツールサポートが受けられなかったりする。 Fowlerの見解では、Transaction Scriptを使うようなシステムで、ここまでする必要性があるケースはめったにないらしい。自社の場合も、FWがうれしいだけで、使っている側にはほと んどメリットがない気がする。あ、SpringのAspectでトランザクション設定が楽になるかな。

使いどころ
ドメインロジックが少なく、シンプルな場合。ロジックが複雑になるにつれ、設計を良い状態に保つのは難しくなる。こういうケースでは、FowlerはDomain Modelを勧めている。