ダイコン時代の設計手法

スタラジで、本来話したかったことをまとめておきます。
最初はユースケースからスタートします。
本当は、RFPユースケースに落とすという工程が
前工程にあります。
ユースケースの粒度について神経質になると
失敗します。
画面系ならいくつかの関連のある画面をまとめたものが
1つのユースケース
ものすごく狭い言い方をするとメニューから呼ばれる
関連のある画面群が1つのユースケース
帳票系なら1つの帳票が1ユースケース
バッチ系なら関連するジョブをまとめたジョブネットが
1つのユースケース


ユースケースを状態とサービスに分離します。
サービスはステートレスです。
状態は永続的な状態とプレゼンテーション層における一時的な状態に
わかれます。
永続的な状態はER分析され、エンティティ(JavaBeans)にマッピングされます。
ここでは、UI層における一時的な状態を
サービスから切り離し、サービスをステートレスにすることがポイント。


次からがいよいよ業務ロジックの分析です。
ここでは2つの選択肢があります。
サービスに業務ロジックをマッピングする方法と
エンティティに業務ロジックをマッピングする方法です。
どちらを選ぶのかは好みなのですが、開発者のほとんどが
オブジェクト指向に精通しているという特殊なケースを除いては、
サービスに業務ロジックをマッピングするのが無難です。


サービスに業務ロジックをマッピングする場合、
業務ロジックをどのように実現するかという観点から更に
ロジックを細分化します。
ロジック分割も粒度について神経質になると失敗します。
基本は、あるロジックをどのようにして実現するのかを
1センテンスづつ書き出していき、個々の1センテンスが
1つのサブロジックになります。各センテンスのレベルは合わせます。


ロジック分割していくと、そのロジックの種類は、3つに分かれます。

  • ユースケース固有のロジック
  • データにアクセスするロジック
  • 共通的なロジック

ユースケース固有のロジックは、ユースケースに一対一で対応する
サービスにマッピングします。
データにアクセスするロジックは、エンティティに一対一で対応する
DAOにマッピングします。
共通的なロジックは、staticなユーティリティメソッドか
共通サービスにマッピングします。


これで設計は終了。サービス、DAOのインターフェースが決まり、
ユーティリティメソッドが洗い出されています。
ユーティリティメソッドの実装が終われば、
プレゼンテーション、サービス、DAOを平行で開発することができます。


ダイコン時代は設計方法もシンプルです。