ドメイン層とデータソース層

無難かなぁと思うレイヤ構成:

• Service Layer
  • トランザクション制御、セキュリティ制御を行う。
  • ユースケース依存。
  • 必要に応じて Remote Facade に。

• Table Module
  • 行ではなく表ごとに1インスタンス。
  • 参照、更新、削除が1ヶ所に記述できる。
  • オブジェクト指向っぽくない。

• Table Data Gateway
  • いわゆる DAO。
  • 参照、更新、削除が1ヶ所に記述できる。

• Data Transfer Object (DTO)
  • エンティティが保有するデータ。
  • get/set のみ。
  • ビジネスロジックは持たない。
  • 全てのレイヤで利用可。

ナイーブなオブジェクト指向に憧れつつ、
結局こんなふうに考えているのですが...

今日、会社の若手エンジニアたちが、
Spring + Hibernate の上に Domain Model で
業務ロジックを書こうとしているという話を聞いて、
今さらながらもう一度自分でも試してみました。

もしかしたら行けるかもと思ったのですが、
Hibernate を使ったとしてもまだまだ課題がありそうです。

• DTO と Domain Model の間でデータの詰め替えが必要。
• Domain Model に記述するビジネスロジックの、インタフェースと実装の分離は必要ないか?
• 参照・新規と更新・削除ではビジネスロジックを記述する場所が異なる。
• データの更新前に検査をする場合、そのロジックはどこに記述すべきか?
• データの更新後に検査をする場合、検査が NG のときの復旧をどうするか?
• 更新は Hibernate が自動でやってくれるので良いが、
  削除時に Domain Model は Hibernate の Session をどう見つけるか?

などなど。

もし本当にナイーブなオブジェクト指向を実践している人がいるなら、
一度ソースコードを見てみたいものです。
ねぇ Fowler さん。

# この日記、もしかして会社的には NG? (^^;)