PB(Presentation Businesslogic)レイヤアーキテクチャ

Actionをプレゼンテーション層とビジネスロジック層のglueとして使う場合、レイヤとしては、プレゼンテーション層とビジネスロジック層の2層構造になります。データアクセス層はDaoとしてビジネスロジック層に吸収します。ActionからDaoを呼び出す場合もあるためです。ビジネスロジックは、ドメインロジック、データアクセスロジック(Dao)、アプリケーションロジックで構成されると考えてもそんなに違和感無いんじゃないかと思います。
その場合の各層は次のようなクラスで構成されます。

• プレゼンテーション層
  • View
    • JSP、HTMLなど
  • プレゼンテーションロジック
    • ページングなどプレゼンテーションにかかわるロジック
    • ActionにDIされる
  • プレゼンテーションモデル
  • Action
    • プレゼンテーション層とビジネスロジック層のglue(Controler)
    • トランザクション境界
    • プレゼンテーションロジックを呼び出す
    • Dxoを使ってプレゼンテーションモデルとドメインモデルの変換を行う
    • ドメインロジックを呼び出す
    • アプリケーションロジックを呼び出す
    • Daoを呼び出す
  • Dxo
    • ActionにDIされる
• ビジネスロジック層
  • アプリケーションロジック
    • ActionにDIされる
    • アプリケーションロジックがアプリケーションロジックを利用している場合アプリケーションロジックにDIされる
  • (ドメインロジック)
    • リッチドメインモデルの場合はドメインモデルに統合
    • シンドメインモデルの場合はActionにDIされる
    • アプリケーションロジックがドメインロジックを利用している場合アプリケーションロジックにDIされる
  • ドメインモデル
  • Dao
    • データアクセスロジック
    • ActionにDIされる

リッチドメインモデルの検索系の場合、次のような処理が行われます。

1. Actionがプレゼンテーションモデル(検索条件)を受け取る。
2. ActionはDaoを使って、ドメインモデルを取得する。
3. ActionはDxoを使って、ドメインモデルをプレゼンテーションモデルに変換する。

リッチドメインモデルの更新系の場合、ビジネスロジック層では次のような処理が行われます。

1. Actionがプレゼンテーションモデルを受け取る。
2. ActionはDxoを使って、プレゼンテーションモデルをドメインモデルに変換する。
3. ActionはDaoを使って、ドメインモデルを永続コンテキストに登録する
4. Actionはドメインモデルのドメインロジックを呼び出す
5. 必要ならActionはアプリケーションロジックを呼び出す

Actionのメソッドにはトランザクション用のAOPが設定されているので、メソッドが開始するときにトランザクションが開始され、メソッドが終了するときに、自動的にO/R MapperによりSQL文が発行され、コミットされます。


シンドメインモデルの検索系の場合、リッチドメインモデルの場合と同じです。


シンドメインモデルの更新系の場合、リッチドメインモデルとの違いは、4の部分で、ドメインモデルを引数にしてドメインロジックを呼ぶ部分だけです。


Actionがアプリケーションロジック、ドメインロジック、Daoを直接呼び出すようにした場合、ビジネスロジックの仕様が変わるとActionにも影響が及んでしまいますが、その仕様変更は、アプリケーションロジック、ドメインロジック、Daoにカプセル化されていますから、特に問題なさげですね。
Dxoはプレゼンテーション層に所属していながら、実際にコードを書く人は業務に精通しているビジネスロジック層の人になると思われますが、これはしょうがないですね。