データ ポイント - ドメイン駆動設計のコーディング: データを重視する開発者のためのヒントより。
ドメインのモデル化とは、ビジネスのタスクに注目することです。
(中略)
データの永続性はアプリケーションで補助的な役割しか果たしません。
(中略)
境界コンテキストの DDD 手法を採用すれば、動作に注目しながら DDD の指針に従って型を構築することになるので、現在構築しているシステムよりも永続性を大幅に簡略化できます。
ドメインモデリングの際は永続化(=データモデル)について考える必要はない。永続化時のデータモデルとアプリケーション上のドメインモデルは別物である、と言いたいのだと思われる。
とはいえ、最終的にはデータモデルも検討する必要があると思うが。
もう 1 つの教訓は、プロパティ セッターをプライベートにすることです。呼び出し元コードでさまざまなプロパティを不規則に設定できるようにするのではなく、プロパティを変更するメソッドを使用して、DDD オブジェクトとその関連データの操作を管理する必要があります。
単純なセッターはドメイン知識を表現していないのでNGということだと思われる。モデルの状態を変更するということは、何らかの意図された操作であるはずなので、その意図を表現する必要がある、ということだろう。
アプリには、DDD を使用しなくても作成できる部分があります。DDD が役に立つのは、複雑な動作を処理する場合です。
(中略)
多くの場合、アプリケーションには複雑な動作と単純な CRUD の組み合わせが含まれています。そのため動作を明確にすることに時間を割いて、実際には単純なアプリケーションの構成要素の過剰設計で時間、労力、および経費を無駄にしないようにします。
原則としてドメイン駆動設計は手間と工数がかかる。したがって、単純なCRUD操作で完結するアプリケーションなら、あえてドメイン駆動設計を使うことで手間と工数を余分にかける必要はない、という意味だと思われる。