ビジネスロジック層とドメインモデル
ビジネスロジック層は次のようなクラス(アプリケーションロジックもドメインロジックも1つのクラス)で構成されます。
ドメインロジックを()で囲っているのは、ドメインロジックをドメインモデルに持たせた場合、ドメインロジックは、ビジネスロジック層に含まれないためです。
ドメインモデルにドメインロジックが含まれる場合をリッチドメインモデルと呼び、ドメインモデルにドメインロジックが含まれない場合をシンドメインモデルと呼ぶことにします。
ドメイン層ではなく、ビジネスロジック層という言葉を使ったのは、リッチドメインモデル場合、ドメイン層がなくなってしまうためです。
ビジネスロジック層の構成と処理は、リッチドメインモデルとシンドメインモデルで若干異なることになります。
リッチドメインモデルの検索系の場合、ビジネスロジック層では次のような処理が行われます。
- サービスがプレゼンテーション層からプレゼンテーションモデル(検索条件)を受け取る。
- サービスはDaoを使って、ドメインモデルを取得する。
- Employee emp = employeeDao.getEmployee(employeeName);
- サービスはDxoを使って、ドメインモデルをプレゼンテーションモデルに変換する。
- EmployeePresentation empPresen = employeeDxo.toPresentation(emp);
- プレゼンテーションモデルをプレゼンテーション層に返す
リッチドメインモデルの更新系の場合、ビジネスロジック層では次のような処理が行われます。
- サービスがプレゼンテーション層からプレゼンテーションモデルを受け取る。
- サービスはDxoを使って、プレゼンテーションモデルをドメインモデルに変換する。
- Employee emp = employeeDxo.toDomain(empPresen);
- サービスはDaoを使って、ドメインモデルを永続コンテキストに登録する
- employeeDao.merge(emp);
- サービスはドメインモデルのドメインロジックを呼び出す
- 必要ならサービスはアプリケーションロジックを呼び出す
サービスのメソッドにはトランザクション用のAOPが設定されているので、メソッドが開始するときにトランザクションが開始され、メソッドが終了するときに、自動的にO/R MapperによりSQL文が発行され、コミットされます。
シンドメインモデルの検索系の場合、ビジネスロジック層での処理はリッチドメインモデルの場合と同じです。
シンドメインモデルの更新系の場合、ビジネスロジック層では次のような処理が行われます。
- サービスがプレゼンテーション層からプレゼンテーションモデルを受け取る。
- サービスはDxoを使って、プレゼンテーションモデルをドメインモデルに変換する。
- Employee emp = employeeDxo.toDomain(empPresen);
- サービスはDaoを使って、ドメインモデルを永続コンテキストに登録する
- employeeDao.merge(emp);
- サービスはドメインモデルを引数にしてドメインロジックを呼び出す
- 必要ならサービスはアプリケーションロジックを呼び出す
リッチドメインモデルとの違いは4の部分だけですね。
サービスをサービス層としてビジネスロジック層から分離していないのは、サービスはデータアクセス層(Dao)を直接(ビジネスロジック層をパスして)呼び出す場合もあるからです。
シンドメインモデルは、ドメインに仕様上は依存していますが、実装上はドメインロジックには依存していません。
