ドメイン駆動設計（DDD）を学ぼうとしていますが、基本的な考え方はわかったと思います。しかし、私を混乱させる何かがあります。
DDDでは、永続性モデルとドメインモデルは異なるものですか？つまり、ドメインの懸念のみを念頭に置いてドメインとクラスを設計します。大丈夫。しかし、その後、リポジトリやその他のデータ永続化システムを構築するときに、永続化レイヤーで使用するモデルの別の表現を作成する必要がありますか？
私たちのドメインモデルは永続的にも使用されていると思っていました。つまり、リポジトリはクエリからドメインオブジェクトを返します。しかし、今日、私はこの投稿を読みました、そして私は少し混乱しています：
それが本当なら、ドメインオブジェクトから個別の永続オブジェクトを持つことの利点は何でしょうか？
このように考えると、ドメインモデルは何にも依存せず、インフラストラクチャコードを含まないようにする必要があります。ドメインモデルは、シリアル化可能であったり、一部のORMオブジェクトから継承したり、共有したりしないでください。これらはすべてインフラストラクチャの懸念事項であり、ドメインモデルとは別に定義する必要があります。
しかし、それは、純粋なDDDを探していて、プロジェクトが初期開発の速度よりもスケーラビリティとパフォーマンスを重視している場合です。多くの場合、インフラストラクチャの懸念事項を「ドメインモデル」と組み合わせると、スケーラビリティを犠牲にして速度を大幅に向上させることができます。重要なのは、「純粋なDDDのメリットは、開発のスピードにおいてコストに見合うだけの価値があるのか」ということです。あなたの答えがイエスなら、ここにあなたの質問への答えがあります。
アプリケーションがドメインモデルで始まり、データベース内のテーブルがドメインモデルと完全に一致するという例から始めましょう。これで、アプリケーションが飛躍的に成長し、データベースにクエリを実行するときにパフォーマンスの問題が発生し始めます。よく考えられたインデックスをいくつか適用しましたが、テーブルが急速に大きくなっているため、データベースを非正規化する必要があるようです。したがって、dbaを使用すると、パフォーマンスのニーズを処理する新しいデータベース設計を思い付くことができますが、テーブルは以前とは大きく異なり、ドメインエンティティのチャンクは複数のテーブルに分散されます。エンティティごとに1つのテーブルであるよりも。
これはほんの一例ですが、ドメインモデルを永続性モデルから分離する必要がある理由を示しています。この例では、ドメインモデルのクラスを分割して、永続性モデルの設計に加えた変更と一致させ、ドメインモデルの意味を本質的に変更する必要はありません。代わりに、新しい永続性モデルとドメインモデルの間のマッピングを変更する必要があります。
スケーラビリティ、パフォーマンス、緊急データベース変更への対応時間など、これらの設計を分離しておくことにはいくつかの利点がありますが、初期開発のコストと速度と比較検討する必要があります。一般に、このレベルの分離から最大の利益を得るプロジェクトは、大規模なエンタープライズアプリケーションです。
コメンテーターのための更新
ソフトウェア開発の世界では、考えられる解決策はN番目にあります。このため、柔軟性と開発の初期速度の間には間接的な逆の関係があります。簡単な例として、ロジックをクラスにハードコーディングしたり、動的ロジックルールをクラスに渡すことができるクラスを作成したりできます。前者のオプションの方が開発速度は速くなりますが、柔軟性は低くなります。後者のオプションは柔軟性が高くなりますが、開発速度が遅くなります。考えられる解決策は常にN番目にあるため、これはすべてのコーディング言語に当てはまります。
初期の開発速度と柔軟性を高めるのに役立つ多くのツールが利用可能です。たとえば、ORMツールを使用すると、データベースアクセスコードの開発速度が向上すると同時に、ORMがサポートする特定のデータベース実装を柔軟に選択できるようになります。あなたの観点からすると、これは時間と柔軟性の両方の純利益からツールのコスト（一部は無料）を差し引いたものであり、開発時間のコストに基づいて価値がある場合とない場合があります。ビジネスニーズ。
ただし、基本的にドメイン駆動設計であるコーディングスタイルでのこの会話では、使用しているツールの作成にかかった時間を考慮する必要があります。そのORMツールを作成する場合、またはツールが提供するすべての実装をサポートするようにデータベースアクセスロジックを作成する場合でも、計画している特定の実装をハードコーディングする場合よりもはるかに時間がかかります。使用について。
要約すると、ツールは、多くの場合、ツールを購入するすべての人にその時間のコストを分配することによって、生産と柔軟性の価格に自分の時間を相殺するのに役立ちます。ただし、ツールを使用するコードを含むすべてのコードは、速度と柔軟性の関係の影響を受けたままになります。このように、ドメイン駆動設計では、ビジネスロジック、データベースアクセス、サービスアクセス、およびUIコードをすべて一緒に絡ませた場合よりも柔軟性が高くなりますが、本番環境では時間がかかります。ドメイン駆動設計は、小規模なアプリケーションよりもエンタープライズレベルのアプリケーションに適しています。これは、エンタープライズレベルのアプリケーションは、ビジネス価値に関連して初期開発時間のコストが高くなる傾向があり、より複雑であるため、変更の影響を受けやすく、より高い柔軟性が必要になるためです。時間のコストを削減しました。
DDDでは、永続性モデルとドメインモデルは異なるものですか？
DDDには、ドメインモデルとリポジトリがあります。それでおしまい。リポジトリ内にある場合は、ドメインモデルを直接永続化するか、永続化する前に永続化モデルに変換します。それはデザインの問題です、あなたのデザイン。これはリポジトリの実装の詳細であり、ドメイン自体には関係ありません。
他の回答者が指摘しているように、各オプションには長所と短所があります。私がそれらのいくつかを詳述しているこの答えを見てください。
DDDでは、永続性モデルとドメインモデルは異なるものですか？
はい。ただし、永続性モデルを明示的に表すために、必ずしも異なるクラスのセットを意味するわけではありません。
永続性にリレーショナルデータベースを使用する場合、NHibernateなどのORMは、ドメインクラスへのマッピングを通じて永続性モデルの表現を処理できます。この場合、明示的な永続性モデルクラスはありません。このアプローチの成功は、ORMのマッピング機能に依存します。たとえば、NHibernateは、コンポーネントマッピングを介して中間マッピングクラスをサポートできます。これにより、必要に応じて明示的な永続性モデルクラスを使用できます。
永続化にドキュメントデータベースを使用する場合、ドメインモデルは永続化するためにシリアル化可能である必要があるだけなので、通常、永続化モデルの必要性はさらに少なくなります。
したがって、ドメインモデルへのORMマッピングでは達成できない複雑なマッピングがある場合は、明示的な永続性モデルクラスを使用してください。ドメインモデルと永続性モデルの違いは、実装に関係なく残ります。