ダイコン時代の設計手法 - 内部設計
バウンダリに関しては、UI層のフレームワークに合わせた
内部設計書を作成します。
とりあえず、必要だと思われるのは、UI層のコントローラ
(例えばStrutsのAction)のコンポーネント定義です。
UI層のコントローラは、ロジック層のクラス(interface)に依存します。
依存関係もコンポーネント仕様書に記述します。
ロジック層とは、以前サービス層と呼んでいた層です。
SOAの絡みでややこしくなりそうなので、呼び方を変えました。m(_ _)m
コントロールの内部設計が最も重要なポイントです。
コントロールの処理を
- 業務固有の部分
- 永続化に関する部分
- 共通部分
に分解します。
業務固有の部分は、ロジック層のコンポーネントで実装します。
ロジック層のコンポーネントはバウンダリごとに作成します。
例えば、従業員管理初期ページに
- 新規入力を行う
- 検索を行う
という2つのコントロールがあった場合、
従業員管理初期Logicクラスに
- 新規入力を行う
- 検索を行う
というコントロールに1:1に対応するメソッドが用意され
業務固有の部分を実装することになります。
このコントロールに対応したメソッドはバウンダリから呼び出されます。
コンポーネント仕様書では、メソッドごとに事前条件・事後条件を記述します。
事前条件とは、メソッドを呼び出すために必要な引数の条件です。
事後条件には、引数として何をもらったらどういう結果を返すのかという
テスト仕様を記述します。
開発者は仕様書を書きながらテスト内容も同時に考えているので、
何を実装しなければいけないのかが明確になります。
またレビュー時にテスト仕様も確認できるのでレビューの質も上がります。
永続化に関する処理は、永続化層のDaoで実装されます。
Daoはエンティティごとに作成します。
動的なSQLの生成が必要な場合、その実装は永続化層で行います。
S2Daoの場合は特に実装の必要はありません。
条件によって見に行くエンティティが変わるような
エンティティをまたがる動的なSQLは、ロジック層でどのエンティティが
対象なのかの判定を行い、エンティティが決まった後は、
そのエンティティのDaoに処理を任せます。
共通処理は共通コンポーネントまたは、staticなユーティリティメソッドで
実装します。
エンティティは、エンティティ仕様書より自動生成されるので
内部設計は特に必要ありません。
