2007年11月28日水曜日

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を勧めている。

0 件のコメント: