Re:レイヤアーキテクチャ

Architecture

id:higayasuoさんのレイヤアーキテクチャについて考察してみました。

Action と Service を統合した場合

http://d.hatena.ne.jp/higayasuo/20050825#1124964366
で書かれている内容を図で表すと以下のようになると思います。

単純な検索だけならこれでも良さそうに思えますが、Action の責務が多すぎないでしょうか? Dao、DomainLogic、ApplicationLogic の呼び出し順をプレゼンテーション層の担当者が知らなければいけないのは役割分担が不十分な気がします。

Action と Service を分離した場合

http://d.hatena.ne.jp/higayasuo/20050818#1124351693
http://d.hatena.ne.jp/higayasuo/20050817#1124260949
の内容を同じく図示しました。

やはり僕はこちらの Action と Service を分離した形を推奨します。多かれ少なかれ Service にもビジネスロジックが入ると思いますし、Dao、DomainLogic、ApplicationLogic の呼び出し順もビジネスロジック層で管理することができます。
あと、今まで僕は Dao の呼び出しを DomainLogic が行う形で設計していたのですが、単純な検索の場合冗長になってしまうので、この形もありかなと思いました。

1つ気になった点として、更新系の場合、

  1. サービスがプレゼンテーション層からプレゼンテーションモデルを受け取る。
  2. サービスはDxoを使って、プレゼンテーションモデルをドメインモデルに変換する。
    Employee emp = employeeDxo.toDomain(empPresen);
  3. サービスはDaoを使って、ドメインモデルを永続コンテキストに登録する。
    employeeDao.merge(emp);
  4. サービスはドメインモデルのドメインロジックを呼び出す。
  5. 必要ならサービスはアプリケーションロジックを呼び出す。

と書かれているのですが、チェックをかけてから DB に反映したいので、Dao と DomainLogic の呼び出し順は逆になるのではと思いました。

あと、図を描いて気がついたのですが、Dxo を導入することによって DomainModel の生成が Dao と Dxo に集約されたので、DomainModel の置き換えがやりやすくなったと思います。おかげで DomainModel にビジネスロジックが書きやすくなりました。

Action と Service を分離した場合(リッチドメインモデル)

以上の考察をふまえて、リッチドメインモデル修正バージョンを書いてみました。

以下の点が変更になっています。

  1. DomainLogic と DomainModel を統合した。
  2. 更新系で Dao と DomainLogic(DomainModel) の呼び出し順を逆にした。

また、以前 id:aufheben:20050821 でも指摘したのですが、PresentationModel は Service が提供するモデルと考えた方が汎用的な気がします。一般に DTO と呼ばれているのでそのままでよい気がします。

次回の PofEAA読書会で DomainModel の発表をすることになっているのですが、このモデルをベースに DomainModel の可能性をもう少し探ってみようと思います。