ドメインドリブンデザインの詳細をお読みください。基本的には、ビジネスの要件を、必要なすべてのビジネス論理タスクを実行できる純粋なモデル(大部分はオブジェクトモデル)に取り込もうとします。このモデルは、アプリケーションレイヤーから呼び出すことができます(たとえば、MVCのビューまたはコントローラー、MVPでは、それを呼び出し、PresenterのGUIに合わせて調整します)。モデルはまた、永続性やその他の技術的な事柄を可能な限り知らないようにする必要があります。
このようなドメインモデルにビジネスロジックをカプセル化すると、いくつかの大きな利点があります。
- 再利用性
- 使いやすさと拡張性
- 一般的にはより良いアーキテクチャにつながります
- 一貫性とビジネス要件を明確に伝えます...
- ...開発者、顧客、アナリストなどの間のコミュニケーションを改善します。
ドメインドリブンデザインに関するEric Evanの本をお読みになることをお勧めします。正しい方向を示し、どのロジックをどこに配置するかについての良い例を示します。きっとあなたがそれを読んだ時点で、あなたのエンティティの大部分はフラットなデータ以上のものを含んでいるでしょう。
しかし、モデルがビジネスロジックを処理し、それ自体が完全なクラスであるアプローチを計画するのは難しいと感じています。
モデルでは、主にこのコンテキストでエンティティを参照していると思います。エンティティにビジネスロジック/動作を組み込むことは、簡単な作業ではありません。しかし、あなたは常にエンティティが何を考えるべきであると実体が何を行います。それにはいくつかの責任や行動がありますか?行動や責任がサービスとしてより適切に表現されている場合は、エンティティがフラットであっても問題ない場合があります。
動物がいるとしましょう。その属性はデータベースにフラットに保存できますが、動作もあります。食べる必要があります。しかし、草食動物は肉を食べないので、プログラマーが肉を強制的に消費させたいときに、その行動を確実に示す必要があります。それは動くことができ、それはそれ自身の独特のノイズを作ることができます。これらは、たとえばエンティティにモデル化する必要があるものです。これらの動物に食べさせたり、動かしたり、騒がせさせたりするために、手続き的なサービスに頼る必要はないでしょう。
しかし、すべての例は具体的なビジネスドメインなしでは浅いです。だからあなたのビジネスドメインとそのエンティティ、行動、責任について考えてください。他のビジネスドメインには、部外者にはほとんど同じに見えるエンティティが含まれている可能性がありますが、実際にはまったく異なるものであるか、まったく異なる動作を示します。モデルは何よりもまず、ユーザーのドメインをできるだけ正確に描写する必要があります。