最近携わっているプロジェクトでは、きちっとしたレイヤーモデルアーキテクチャを採用しています。それについてのまとめです。
レイヤーモデルアーキテクチャは多少冗長な部分もあるのですが、
によってかなりすっきりとしたコードになります。現在採用しているのは、
- プレゼンテーション層（アクション＋ビュー）
- ビジネスロジック層（サービス等）
- データアクセス層(SQLやDAO）
の3階層になります。プレゼンテーション層からデータアクセス層を参照する事はありません。プレゼンテーション層はビジネスロジック層に依存し、ビジネスロジック層はデータアクセス層にのみ依存します。これらの層を繋ぐオブジェクトがデータトランスファーオブジェクト（DTO)となります。
自分の場合はドメインモデルよりもトランザクションスクリプトが好きなので、基本的にはDTOの利用がメインとなります。せいぜいドメインモデルとなるのはActionFormくらいでしょうか。プレゼンテーション層のドメインモデルはサービスに対して直接渡しません。サービスがプレゼンテーション層に依存してしまうからです。
上記構成ではサービスやDAOが存在しなくてもアクションやビューが作成できます。それはサービスのインターフェイスを用意することにより、モックを作成することができ、アクションはサービスの完成を待つ必要がないからです。また、サービスはHttpに関するAPIは一切触りません。黙々とデプロイ不要なままmainメソッドを利用してサービスの実装ができ、作成されたサービスはバッチ処理などからも使う事が出来ます。
トランザクション境界はサービスのメソッド単位となります。プレゼンテーション層でトランザクションを意識する必要はありません。ロールバックもコミットも知る必要はないのです。あくまでサービスが成功したのか失敗したのかがプレゼンテーション層に伝わればよいのです。
ここで冗長となるのが、ドメインモデルやエンティティからDTOに詰め替える処理です。この辺をツールやライブラリでサポートすると、かなりすっきりしたコードになります。各層間の依存関係の解決をDIコンテナに任せる事により、面倒な手続きを省略したり、モックと実装の切り替えが設定ファイル1つで済んだりしてサクサクとした開発となるでしょう。