DDD-永続性モデルとドメインモデル
ドメイン駆動設計（DDD）を学ぼうとしていますが、基本的なアイデアは得られたと思います。しかし、私を混乱させる何かがあります。
DDDでは、永続性モデルとドメインモデルは異なるものですか？つまり、ドメインの問題だけを念頭に置いてドメインとクラスを設計します。大丈夫。しかし、その後、リポジトリまたは他のデータ永続性システムを構築するとき、永続化レイヤーで使用するモデルの別の表現を作成する必要がありますか？
私たちのドメインモデルは永続性でも使用されていると考えていました。つまり、リポジトリはクエリからドメインオブジェクトを返します。しかし、今日、私はこの投稿を読みましたが、少し混乱しています。
それが本当なら、永続化オブジェクトをドメインオブジェクトから分離することの利点は何でしょうか？
このように考えると、ドメインモデルは何にも依存せず、インフラストラクチャコードが含まれていないはずです。ドメインモデルは、シリアライズ可能であったり、いくつかのORMオブジェクトを継承したり、共有したりするべきではありません。これらはすべてインフラストラクチャの問題であり、ドメインモデルとは別に定義する必要があります。
しかし、それは、純粋なDDDを探している場合で、プロジェクトは初期開発の速度よりもスケーラビリティとパフォーマンスを重視している場合です。多くの場合、インフラストラクチャの懸念と「ドメインモデル」を組み合わせることで、スケーラビリティを犠牲にして速度を大幅に向上させることができます。重要なのは、「純粋なDDDの利点は開発速度のコストに見合うだけですか？」と自問する必要があるということです。あなたの答えがイエスの場合、ここにあなたの質問への答えがあります。
アプリケーションがドメインモデルで始まる例から始めましょう。データベースのテーブルがドメインモデルと正確に一致することが起こります。これで、アプリケーションが飛躍的に成長し、データベースのクエリ時にパフォーマンスの問題が発生し始めます。よく考えられたいくつかのインデックスを適用しましたが、テーブルが非常に急速に成長しているため、維持するためにデータベースを非正規化する必要があるようです。したがって、dbaの助けを借りて、パフォーマンスニーズを処理する新しいデータベース設計を思いつきますが、テーブルは以前とは大きく異なり、ドメインエンティティのチャンクは複数のテーブルに分散していますエンティティごとに1つのテーブルであるよりも。
これはほんの一例ですが、ドメインモデルを永続性モデルから分離する理由を示しています。この例では、永続性モデルの設計に加えた変更に合わせてドメインモデルのクラスを分割し、ドメインモデルの意味を本質的に変更する必要はありません。代わりに、新しい永続性モデルとドメインモデルの間のマッピングを変更する必要があります。
スケーラビリティ、パフォーマンス、緊急データベースの変更に対する反応時間など、これらの設計を分離しておくことにはいくつかの利点がありますが、初期開発のコストと速度と比較検討する必要があります。一般に、このレベルの分離から最も利益を得るプロジェクトは、大規模なエンタープライズアプリケーションです。
コメンテーターの更新
ソフトウェア開発の世界では、N番目の可能な解決策があります。このため、柔軟性と開発の初期速度の間に間接的な逆の関係が存在します。簡単な例として、ロジックをクラスにハードコーディングするか、動的ロジックルールをクラスに渡すことができるクラスを記述することができます。前者の方が開発速度は速くなりますが、代償として柔軟性が低下します。後者のオプションは、柔軟性が高くなりますが、開発速度が遅くなります。常にN番目の数の解決策があるため、これはすべてのコーディング言語で当てはまります。
初期の開発速度と柔軟性を高めるのに役立つ多くのツールが利用可能です。たとえば、ORMツールを使用すると、データベースアクセスコードの開発速度が向上すると同時に、ORMがサポートする特定のデータベース実装を柔軟に選択できるようになります。あなたの観点からは、これは時間と柔軟性の両方の純利益からツールのコスト（一部は無料）を差し引いたものです。ツールの価値に対する開発時間のコストに基づいて価値がある場合とない場合がありますビジネスニーズ。
ただし、コーディングスタイルでの会話（これは本質的にはドメインドリブンデザインです）では、使用しているツールの作成にかかった時間を考慮する必要があります。 ORMツールを作成する場合、またはツールが提供するすべての実装をサポートするようにデータベースアクセスロジックを作成する場合でも、計画する特定の実装をハードコーディングする場合よりもはるかに時間がかかります。使用中。
要約すると、ツールは、多くの場合、ツールを購入したすべての人にその時間のコストを分配することにより、生産までの時間と柔軟性の価格を相殺するのに役立ちます。ただし、ツールを利用するコードを含むコードは、速度と柔軟性の関係の影響を受けたままです。このように、ドメインドリブンデザインは、ビジネスロジック、データベースアクセス、サービスアクセス、およびUIコードをすべて一緒にもつれた場合よりも高い柔軟性を可能にしますが、生産に時間がかかります。ドメインドリブンデザインは、エンタープライズレベルのアプリケーションはビジネス価値に関連して初期開発時間のコストが高くなる傾向があり、より複雑であるため、変更の影響を受けやすいため、小規模アプリケーションよりもエンタープライズレベルのアプリケーションに適しています。時間のコストを削減。
DDDでは、永続モデルとドメインモデルは異なるものですか？
はい。ただし、永続モデルを明示的に表すために、異なるクラスのセットを必ずしも意味するわけではありません。
永続性にリレーショナルデータベースを使用している場合、NHibernateなどのORMは、ドメインクラスへのマッピングを通じて永続性モデルを表すことができます。この場合、明示的な永続化モデルクラスはありません。このアプローチの成功は、ORMのマッピング機能に依存します。たとえば、NHibernateは component mappings を介して中間マッピングクラスをサポートできます。これにより、必要に応じて明示的な永続モデルクラスを使用できます。
永続化にドキュメントデータベースを使用する場合、永続化するためにドメインモデルのみをシリアル化する必要があるため、通常、永続化モデルの必要性はさらに少なくなります。
したがって、ドメインモデルへのORMマッピングでは達成できない複雑なマッピングがある場合は、明示的な永続性モデルクラスを使用します。ドメインモデルと永続性モデルの違いは、実装に関係なく残ります。
DDDでは、永続モデルとドメインモデルは異なるものですか？
DDDには、domainモデルとrepositoryがあります。それでおしまい。リポジトリ内でドメインモデルを直接永続化するか、永続化する前に永続化モデルに変換します。それはデザインの問題、あなたのデザインです。
他の質問者が指摘したように、各オプションには長所と短所があります。これを見てみましょうanswerここでいくつかを詳しく説明します。
ドメインモデルは永続性モデルとは異なり、それは何であれ真実です。
説明させてください。
永続化ストアとしてRDBを使用している場合、永続化モデルが必要であるかどうかにかかわらず、ORMを使用し、他のORMよりも1つのORMを選択することが非常に大きな影響を与えると考えてください。
どうして ？
.NETの世界で最もよく使用される2つのORMを比較しましょう。
最初のエンティティフレームワーク
関係を理解するには、次のコードが必要です。
public class Aggregate
{
public int Id { get; }
/// relation
protected internal virtual IList<Entity> Model { get; private set; }
}
public class Entity
{
public int Id { get; }
/// relation
public int AggId{ get; private set;}
public Aggregate Aggregate { get; private set; }
}
ここで、NHibernateを見てみましょう。これが、ドメインモデルのモデル化方法です。
public class Aggregate
{
public virtual int Id { get; }
protected internal virtual IList<Entity> Model { get; private set; }
}
public class Entity
{
public virtual int Id { get; }
}
そのため、一方を使用してモデリングする方法ともう一方を使用してモデリングする方法の違いに注目してください。
EFの問題点についてお話しましょう。私の観点から、ここで起こっている2つの非常に重要なドメイン違反があります。
1日ご覧のとおり、DBスキーマのモデル化方法を知るために、EFは相互参照を必要とします。さらに、ある時点で多対多のリレーションを作成する場合は、2つのドメインモデルに参照を追加する必要があるだけでなく、3番目のクラス（結合クラス）を追加する必要があります。ドメイン概念としてそれをモデル化する方法を考えてください、それはAggregate、EntityまたはValueObjectですか？現実には、ビジネスにはまったく価値がありません。なぜモデル化を余儀なくされるのでしょうか？ドメインでは、ビジネスニーズのみを考慮し、ストレージに対するデータの表現方法は考慮しないでください。
2番目。これを参照してください http://www.informit.com/articles/article.aspx?p=2020371&seqNum=4
あなたはそれについて何ができますか？ EFを使用している場合、正しく実行すると、おそらくドメインモデル（この単純な場合はNHibernateモデルのようになります）およびDBスキーマのミラーとなる永続性モデルを使用できます。ドメインモデルはドメインにあり、永続性モデルはインフラストラクチャにあります。
NHibernateに戻ります。ドメインモデルはデータモデルと同じであると考えることができます。もちろん、インフラストラクチャでいくつかの構成を使用して永続ストアに対する正しい関係をモデル化しますが、NHibernateはドメインに何かを追加することを強制しません。必要ありません。
私はORMを他よりも宣伝していません。それらのいずれかを使用することは誰もが選択できます。あなたのビジネスニーズによって決定されるべき選択です。
では、NoSQL（スキーマレス）はどうでしょうか？ドメインモデルは永続性モデルと同じであり、関係をモデル化するための構成は必要ありません。