web-dev-qa-db-ja.com

DDD：エンティティバリエーションを使用するには

従業員を表すエンティティがあるとします。

Employee
    First name
    Last name
    Birthdate
    Hair color
    Eye color
    Gender
    .... (and so on)

次に、ホームページとプロフィールページの2ページのウェブサイトがあるとします。

ホームページには、最近登録した10名の社員の名前と性別が表示されます。このような：

David (male)
Frank (male)
Anna (female)
Bob (male)
Lynda (female)

従業員名をクリックすると、選択した従業員のすべてのデータを表示するプロファイルページが表示されます

ホームページに名前が必要なだけなので、データベースからモデル全体をロードしても意味がありません（性別や髪の色などは必要ありません。名前だけが必要です。従業員がエンティティははるかに多くのデータを持っていた）。

DDDでこの状況をどのように処理しますか？これは境界のあるコンテキストの問題ではないようです。エンティティのさまざまなバリエーションを作成する必要がありますか？例えば：

Employee
    First name
    Last name
    Birthdate
    Hair color
    Eye color
    Gender

LastEmployee
    First name
    Gender
domain-driven-designdomain-modelentity
4
hendoe

問題は、一般に、どのアプリケーション設計でも、書き込みモデルと1つ以上の読み取りモデルの2種類のモデルがあることです。従来のアプリケーションアーキテクチャスタイルでは、2つのタイプのモデルが1つに統合され、モデルの実装に問題が発生します。

解決策はCQRSであり、より正確にはCQRSで考えるです。つまり、存在するモデルについて考えるとき、書き込みモデル（状態の変化を担うモデル）と1つ以上の読み取りモデルを想像します（状態の読み取り/表示/表示を担当するモデル）。

完全なCQRSアーキテクチャでは、2つのタイプのモデルに対して異なるデータベースがありますが、ここまで進む必要はありません。書き込みモデル、つまりEmployeeのDDD用語での集計と、2つの使用例（EmployeeDetailsとLastEmployee）の2つの読み取りモデルを作成できます。 2つの読み取りモデルと書き込みモデルの同期を維持するためにドメインイベントを使用しない場合は、書き込みモデルと読み取りモデルに同じデータベース/テーブルを使用できますが、データのフェッチに異なるサービスを使用できます。

だから、あなたは持つことができます：

  1. EmployeeRepositoryクラスの従業員集約、load/saveメソッド、
  2. ListOfEmployeeDetails読み取りモデルのEmployeeDetailsクラス、検索/ロードメソッド、および
  3. ListOfLastEmployeeLastEmployeeのクラス、検索/ロードメソッド、

同じデータベーステーブル/コレクションにアクセスするこれらすべてのクラス。

これは100％CQRSではありませんが、CQRSのようなアプリケーションです。

4
Constantin Galbenu