web-dev-qa-db-ja.com

技術的な制約がない場合に、ドメインモデルにマップされたORMとの多対多の関係を処理するにはどうすればよいですか？

ドメインドリブンデザインは、ドメインの専門家が使用するユビキタス言語を反映するドメインモデルが必要であると述べています。 ORMと多対多の関係を使用する場合、これを行うのに慣れています。

public class Student
{
    public Student() 
    {
        this.Courses = new HashSet<Course>();
    }

    public int StudentId { get; set; }
    [Required]
    public string StudentName { get; set; }

    public virtual ICollection<Course> Courses { get; set; }
}

public class Course
{
    public Course()
    {
        this.Students = new HashSet<Student>();
    }

    public int CourseId { get; set; }
    public string CourseName { get; set; }

    public virtual ICollection<Student> Students { get; set; }
}

ただし、EF Coreでは、以下の説明に従って結合クラスを作成する必要があります： https://github.com/aspnet/EntityFrameworkCore/issues/1368 。上記の場合; StudentCourseというクラスを作成する必要があります。

EF Coreのような技術的な制約がなく、現在結合クラスを持っている必要がある場合、ORMをドメインモデルにマップする最も適切な方法は何ですか？私の考えは：

1）結合テーブルに状態と動作がある場合は、結合クラスを使用します。

2）結合テーブルの名前がドメインの専門家によって認識されている場合は、結合クラスを使用します。人はローンの対象となる可能性があります-ここで対象となるのは参加クラスであり、ドメインによって認識される用語です。上記の場合; StudentCourseはドメインで認識されません。

3）それ以外の場合（上記の例のように）結合クラスを使用しません。

domain-driven-designormefcore
1
w0051977

DDDが提供しようとする包括的なパラダイムは、システムの動作に焦点を当てたものです。それ以外はすべて実装の詳細です。したがって、特定の永続化メカニズムに従ってドメインをモデル化するのではなく、ドメインに従って永続化メカニズムをモデル化します。 RDBMSへの永続化を容易にするためにドメインに何らかの「結合」オブジェクトを含めると、不要な結合が作成され、永続化の懸念があるモデルが汚染/難読化されます。

特定の問題は、ORMが必要とするdataモデルと、アプリケーションが必要とするdomainモデルを混合することによって引き起こされます。前者を後者から切り離す以外に、ここで使用するDDDソリューションはありません。

ORMは、必然的に貧弱なdataモデル（メソッドを理由内でシリアル化できない）を生成し、必然的に貧弱なデータストアとの間でマッピングするための優れたtool（凝集メカニズム）です。別の言い方をすれば、ORMは開発者により多くのOOエクスペリエンスを提供し、データストアに対する（リークの多い）抽象化を提供するだけです。もう一度？）。

つまり、2種類のアプリケーションがあります。

システムの圧倒的多数は取るに足らないものです。つまり、単純にデータを収集して保持し、それから向きを変えてユーザーに表示します。ささいなアプリケーションはCRUDに要約され、入力されているデータのフォーマット/範囲に関する（ほとんどの場合）いくつかのルールが散在しています。このようなシステムでは、ルールが非常に少ないため、通常はドメインモデルを分離する（またはその一部のみを分離する）必要はありません。

2番目のタイプのアプリケーションは、分離されたドメインから本当に利益を得るアプリケーションです。たくさんのビジネスルールがあるアプリです。多くの場合、この種のアプリケーションは、まったく永続化されないか、多数の集約を含む多くのタイプのオブジェクトを定義します。これにより、ドメインの分離が最も重要になります。 ORMのデータモデルは、すべてのエンティティが使用可能（および変更可能）であるため、（構造ではなく）規律を通じて集約が必要とする整合性の境界のみを提供できます。

この種のアプリケーションを「見た」かどうかは問題ではなく、クリーンアーキテクチャの基本原則を無効にするものではありません。すべての決定はトレードオフです。優れたソフトウェアアーキテクトはそれを理解し、それに応じて行動します。分離ドメインモデルを作成するコストがメリットに値しない場合は、それに応じて先に進みます。しかし、トレードオフを理解してください。それがシステム設計のすべてです。ビジネス上の懸念と技術的な懸念の間の完璧なバランスを見つけることです。それは実用主義についてです。理想主義を学者やジュニアに任せる。開発者、およびCEOへの功利主義。私たちはバランスをとるためにここにいます。それが私たちの価値です。

1
king-side-slide