要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト
今回はアーキテクチャについてです。
レイヤー構成について、3パターンほど私が考える案を紹介します。
各コンポーネントの役割については、別途説明したいと思います。
Full Pattern
- 特徴
- 大規模アプリケーション向け。
- コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。
- Serivceがトランザクション境界となる。
- レイヤー構成
Middle Pattern
- 特徴
- 中規模アプリケーション向け。
- 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、このパターンで十分なケースが多い。
- プレゼンテーションロジック（表示の切替、初期値の設定など）はAction、ドメインロジック（業務自体に関連する処理）はLogicに記述する。
- Dxoは、データオブジェクトの変換を行うだけなので、プレゼンテーション層に位置づけている。
- Actionがトランザクション境界となる。
- レイヤー構成
Lightweight Pattern
- 特徴
- 小規模アプリケーション向け。
- 画面とDBテーブルが1対1で、ロジックはDaoを呼び出すだけ、というシステムに向く。
- ロジックは、ほぼプレゼンテーションロジックだけになるため、Pageに集約してしまう。Pageだけでは1クラスあたりの規模が大きくなってしまい、見通しが悪くなるようならば、PageとActionを分けても良い。
- Pageのdo〜メソッド（もしくはAction）がトランザクション境界となる。
- レイヤー構成
