web-dev-qa-db-ja.com

集約ルートの子を参照するDDD？

DDDを学ぼうとしています。プロパティ管理ドメインをモデリングしていますが、プロパティ管理コンテキストと常駐コンテキストという2つのコンテキスト（サブドメイン？）があると思います。

ApartmentsとFloorplansを保持する集約ルートUnitがあるとします。各Apartmentには多数のFloorplansを含めることができ、各Floorplanには多数のUnitを含めることができます。

_public class Apartment : IAggregateRoot // for clarity
{
    public int Id { get; }
    public Address Address { get; set; }
    public ICollection<Floorplan> Floorplans { get; set; }
}

public class Floorplan
{
    public int Id { get; }
    public int ApartmentId { get; set; }
    public string Name { get; set; }
    public int Bedrooms { get; set; }
    public int Bathrooms { get; set; }
    public ICollection<Unit> Units { get; set; }
}

public class Unit
{
    public int Id { get; }
    public int FloorplanId { get; set; }
    public string Number { get; set; }
}
_

プロパティ管理のコンテキストで、Residentに割り当てられるUnitを紹介するとします。私のUnitおよびResidentクラスは次のようになります。

_public class Unit
{
    public int Id { get; }
    public int FloorplanId { get; set; }
    public string Number { get; set; }
    public ICollection<Resident> Residents { get; set; }
}

public class Resident // in the property management context
{
    public int Id { get; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public void UpdateBalance(...);
}
_

私の質問は、常駐コンテキスト（PayRent()またはUpdateProfile()などが可能）にResidentを導入する場合、プロパティ管理コンテキストでResidentと1：1の関係にある必要があります、しかし、私はApartmentを最後まで通らないと、非集合ルートエンティティを参照できないと思っていました。

集合根についての私の理解は正しくありませんか？ Residentは両方のコンテキストで集約ルートですか？それがどのようにモデル化されるかはわかりません。

c#architecturedomain-driven-design
1
Marlon

DDDの実践者が理解する必要がある最も重要な情報、そして率直に言って、このタグで私が目にする最大の障害は、DDDがシステムのfunctional要件のモデリングに関するものであることです。つまり、DDDは、システムのbehaviorsに焦点を当てた視点を取り、これらの動作をサポートするデータを実装の詳細にするように要求します。

上記の質問では、「this does that」ではなく、「this has that」がたくさんあります。私はあなたのモデルが必ずしも不正確であると言うつもりはありません、むしろあなたはあなたが上で概説した問題に正確につながる方法であなたのシステムをアプローチしていると言います。システム内のデータのみに注目すると（ドメインモデルは物理モデルによく似ていると思います）、ほとんどの場合、「重複」の問題につながります。

この場合、Residentverticallyを動作に応じて分割する必要があります（ただし、IDを共有します）。プロパティ管理コンテキストのResidentにFirstNameおよびLastNameフィールドが必要なのはなぜですか。これらのデータは、コンテキスト内に存在するユースケースに関して重要ですか？ UpdateBalanceまたはRentUnitには名前が必要ですか？おそらく違います。一方、Resident ContextのResidentは、この情報を更新する必要がある場合、これらのフィールドを必要とします。

そして明確にするために、Resident（つまり、FirstNameおよびLastNameフィールドを持つエンティティ）は絶対はアパートメントなしで存在できます。私はここに座っています。常に人工的な制約に注意してください。私はあなたから（まだ！）レンタルしていないかもしれませんが、それでもあなたのシステムが私の存在を知らないわけではありません。この場合、PersonまたはCustomerの方がResidentよりも適切な名前になる可能性があります（後者の場合、これが意味を持つため）。

要約すると、モデルには、永続データストアからの識別子を共有する2つのコンテキスト（常駐管理とプロパティ管理）の2つのエンティティ（PersonとResident）が必要です。それらの存在に関連する特定の動作（異なるフィールドの更新）。これらが同じ物理データベーステーブルにマップするかどうかは、実装の詳細です。

3
king-side-slide