0

私は貧血ドメインモデルがアンチパターンであることについて読んでいて、いくつか質問がありました. 3 つのクライアントが使用するデータベースがあり、それぞれに製品をデータベースに挿入するための異なるビジネス ルールがあります。したがって、リッチ ドメイン モデルを使用すると、コードは次のようになります。

public class Product: IValidatableObject
{
     public int Id;
     public Client Client;
     public int ClientId;

     public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
     {
          if (ClientId == 1)
               DoValidationForClientOne();
          else if (ClientId == 2)
               DoValidationForClientTwo();
          else if (ClientId == 3)
               DoValidationForClientThree();
     }
}

まあ、それは恐ろしいですね。貧血ドメイン モデルがある場合、3 つのサービス レイヤー クラスを簡単に作成できます。これらのクラスには、それぞれ特定のクライアントの検証が含まれます。いいじゃないですか。

私の 2 番目の議論は、デスクトップと Web アプリケーションが同じリッチ ドメイン モデルを使用している場合、HttpException をスローするタイミングとデスクトップ例外をスローするタイミングをどのように知ることができるかということです。分けたほうがいいんじゃない？では最後に、私のプロジェクトでこのような状況で貧血ドメイン モデルがアンチ パターンになるのはなぜでしょうか?

4

3 に答える 3

1

AnaemicDomainModel にはその場所があります。

ドメイン モデルは、プレゼンテーション プラットフォームに固有の例外をスローするべきではありません。プレゼンテーション コードでそれを整理してみましょう。ドメイン モデルがその表現にとらわれないようにすることを目指す必要があります。

于 2012-11-29T16:55:32.487 に答える
1
  1. すでに述べたように、ドメインエンティティではなく、DTO のみを示しました。
  2. DDD では、Product エンティティに直接いくつかの一定の規則を持ち、いくつかの ProductPolicies を使用して、さまざまなコンテキストで製品を処理する際に何が異なるかをカプセル化します。最悪？いいえ、美しくパワフルです。ただし、ドメインが十分に複雑な場合に限ります。そうでない場合は、貧血モデルを使用してください。
  3. ドメインは何にも依存すべきではありません。Web プラットフォーム、デスクトップ プラットフォーム、使用されている ORM、使用されている DI コンテナーについて何も知らないはずです。したがって、例外をスローする場合は、ドメイン カスタム例外にする必要があります。詳細な説明については、タマネギのアーキテクチャまたは六角形のアーキテクチャについてお読みください: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
于 2012-12-04T13:51:22.427 に答える