タイトルを許してください、それは聞こえるより簡単です。エンティティの更新が、エンティティ自体によって、またはサービスクラスによって処理されるべきか？
私はクラスStickerBookを持っています。それはいくつかのステッカー、List<Sticker>を含んでいます。
追加待ちのステッカーがあるかどうか確認するときは、StickerBook.CheckForNewStickers()がそれらを探して追加するロジックか、新しいクラスNewStickerCheckerを確認してStickerBookに追加する必要がありますか？
私が知っているかなり基本的な概念、私はちょうどそれの周りに私の頭を包むことはできません。
これには正解か間違いはありませんか。どちらの方法でも、クラス（List）の内部を一般的には良いものにするのではなく、ロジックをカプセル化しているようです。
ロジックを別のサービスクラスに入れて（このクラスでインターフェイスを実装すると）、このインターフェイスを他のコードに依存関係として渡すと、単体テストが容易になります。私は、サービスクラスを模擬し、複雑なロジックを持つエンティティをモックアップするのではなく、テスト中に実際の単純なエンティティを渡すことは概念的に簡単だと思います。
コードの構造化とオブジェクトのモデリングの一般的なアプローチは何かによって異なります。つまり、単一の責任原則では、オブジェクトには存在する理由が1つしかないと言われているので、NewStickerCheckerをクラスとして好んでいます。
これは白黒ではありません。私の経験では、サブエンティティのコレクションが含まれているエンティティがある場合、あなたのケースでは、その本にステッカーのリストが含まれています。エンティティ。 OOPは、クラスがそのデータを操作するために必要なデータおよびロジックを含むことを定義するすべての;-)
P.S.後
免責条項と同様、エンティティフレームワークのライトではなく、ビジネスエンティティの精神でエンティティのことを話しています（...とにかく、あまりにも多くの変更がありますが、質問のタグ付けのためだけです）。