3

私は DDD をしっかりと理解しようとしており、ドメイン駆動設計に関する Eric Evans の本と、Julie Lerman のブログを読んで、次のように説明しています。

Anemic Domain Model状態管理に焦点を当てたクラスを持つモデルとして。CRUDに適しています。

Entity追跡と永続化に使用される ID を持つ可変クラスとして。

確かに両方とも同じ目的で使用されていますか、それともスティックの端が完全に間違っていますか? 2つの違いは何ですか？貧血ドメイン モデルはデータベース スキーマを表すためによく使用されると読みましたが、エンティティでも同じではないでしょうか?

たとえば、table呼び出された Customer には次のものがあります。

CustomerId int
Forename varchar(50)
Surname varchar(50)
IsActive bit

私の理解では、anemic domain modelこれを表すには次のようになります。

public class Customer
{
  public int CustomerId { get; set; }
  public string Forename { get; set; }
  public string Surname { get; set; }
}

私の過去の経験から、エンティティも一連のプロパティでこのように表されることが示唆されています。これはgetterEntity setterFramework ですか? 両方の概念 (エンティティと貧血ドメイン モデル) はmutable?

ありがとう、DS。

4

2 に答える 2

1

[貧血ドメイン モデルがデータベース スキーマを表すためによく使用されることを読んだことがありますが、エンティティについても同じではありませんか?

Evans の本をもう一度読んだほうがいいかもしれません ;) DDD エンティティは、Rich Domain Model アプローチを実装する 1 つの方法です。エンティティは、アプリケーションのユビキタス言語で参照されるドメイン アクションをキャプチャするという点で豊富です。これらのアクションは、データ スロットの原子的で具体化されていない変更とは対照的に、ビジネス ドメインで発生する可能性のある実際のイベントをエンコードします。たとえばOrder.ApplyDiscountVoucher(...)、プロパティを公開しOrder.Totalて外部スクリプトに任せてバウチャーをチェックし、合計を更新するのではなく、バウチャーの有効性をチェックして注文合計を再計算するメソッドを作成できます。

また、エンティティにカプセル化されているのは、エンティティの作成時、または集約ルートであるエンティティの場合は、誰かが集約を変更しようとするたびに適用できる不変条件を強制する責任です。貧血モデルには、これらのビジネス ルールが組み込まれておらず、外部の手順で対処されます。

エンティティ、他のドメイン オブジェクト、または貧血オブジェクトを変更可能にするかどうかは、これとは完全に直交する問題です。

于 2014-09-10T10:33:51.523 に答える