まず、ドメインモデルが何をさしているのかが人によって違ので、ここではより広い意味で、ドメインを何らかの形で表しているものをドメインモデルと呼ぶことにします。
次が、軽量(lightweight)なドメインモデル。軽量なドメインモデルでは、永続化の方法を気にしながら、モデリングを行ないます。RDBMSを使う場合は、ERモデルとほぼ同じになるように意識してモデリングを行ないます。軽量なドメインモデルとERモデルは同時に設計します。
続ドメインモデル - ひがやすを blog
昨日ちょっと書きましたが、DBの構造に比較的依存する形のドメイン層は現実的なアーキテクチャだと思いますが、それは「ドメインモデル」ではなく、「テーブルモジュール」パターンというもののはずです。「トランザクションスクリプト」と「ドメインモデル」の間のアーキです。
私は現時点ではこれが一番バランスの取れたものだと思っています。パーシステンス層で使うものはO/Rマッパですのでデータマッパーパターンを使うことになりますが、データマッパがテーブル構造に依存しているものである以上、ドメインロジックもテーブルに依存するのはわかりやすいです。もちろん、さらにそれらをまとめるファサードを用意することにより、複数テーブルに依存したロジックを書くパターンですが、サービス層との境目があいまいになります。
データマッパーパターンを利用する場合、エンティティクラスにロジックを書くことは避けるべきです。エンティティはテーブル構造が変更されるたびに更新しなくてはなりませんが、この生成はウィザード等ツールに頼ることになるからです。
