私はこの議論にかなり慣れていませんが、「無知」に聞こえるリスクを冒してでも、この質問をしなければなりません。なぜ今、「DDD」が強調されているのでしょうか。「DDD」を調べれば調べるほど、アプリケーションが複雑になっているようです。一方、データベースを使用してドメインをモデル化すると、レイヤー全体でアプリケーションの一貫性を保つことができます。次に、SubSonic や L2S などの DAL ヘルパーを使用して、そのモデルに簡単にアクセスできます。これの何が悪いの？エンタープライズ アプリケーションでも？
実証済みの方法があるのに、ドメインをモデル化する新しい方法を作成しようとするのはなぜでしょうか?
ここで純粋主義者からの連絡をお待ちしています。
失敗したプロジェクトが多すぎて、とにかく古い方法論を知っている人が多すぎるため、古い方法論を販売することはできません。市場に出すために新しいものがなければなりません。
古い方法でうまくやっているなら、うまくいくものを使ってください。いくつかの本当に素晴らしいアイデアが出てくるので、新しいものに注意を払ってください。しかし、それは古いものすべてが悪くて愚かであるという意味ではありません。通常、新しいアイデアを古いモデルに大幅に組み込むことができます。
行動を起こす時が来ました。構造体と関数ポインタを使ってOOPを実行しないように。;-)
これは実際には非常に優れた質問であり、簡単な答えは「できる」です。以前はそのようにしていましたが、エンタープライズ（データ）モデリングの全領域がありました。実際、一般的なOOD表記はERDから発展したものです。
しかし、私たちが発見したのは、そのようなデータ駆動型の設計にはいくつかの問題があり、その最大の問題は、データベースの自然な構造がコードの自然な構造と必ずしもよく一致しないことです。
OODは、大部分、いくつかの望ましい特性を持つコード構造を見つけやすくしたいという願望から派生しています。
デザインを考えやすくするのは、もともとシミュレーションの「オブジェクト」として現在考えられているものを使用したSimulaに由来します。シミュレーションでは、シミュレートしているものに対応するソフトウェアエンティティがあると便利でした。XeroxのAlankayet alがそれをより一般的な構造化方法と見なしたのは、後になってからでした。
変更時の堅牢性に関する部分には多くの親がいましたが、その中で最も重要なものの1つはDave Parnasでした。モジュール化の基本的なルールを特定するいくつかの論文を書きました。これは、私がParnasの法則と呼んでいます。すべてのモジュールは秘密にしておく必要があります。その秘密は、変更される可能性が高い要件です。
パルナスの法則と、現実の世界で識別できるものに対応する「オブジェクト」というSimulaのアイデアを組み合わせることで、要件の変更に対して、以前の方法よりも堅牢なシステム設計が得られる傾向があることがわかりました。もの。（常にではなく、コマンドパターンのように、巧妙である必要がある場合もあります。ほとんどのオブジェクトは名詞であり、永続的に存在するものです。コマンドパターンでは、理想的なオブジェクトは動詞です。
ただし、その構造がリレーショナルデータベースの基になるデータを表すのに必ずしも良い方法ではないことも判明したため、「オブジェクトリレーショナルインピーダンスの不一致」の問題が発生します。オブジェクトランドからデータベースへの変換を表す方法-土地。
簡単な答え: ユーザーがデータを編集できるようにする CRUD システムだけが必要な場合は、バックエンド データベースへの Access フロントエンドを構築する (または、前述のような足場フレームワークを使用する) だけで済みます。ドメイン駆動型システムと比較して、予算の 70% を削減できるはずです。
長い答え: データ駆動型の設計では、ビジネス モデルの実装はどのようになりますか? 通常、アプリケーションに新機能を追加して数年後には、テーブル、ビュー、ストアド プロシージャ、さまざまなアプリケーション サービス、コード ビハインド ファイル、プレゼンター/ViewModel など、いたるところに重複があることがわかります。 . 彼らが要求している新機能についてドメインの専門家と話しているとき、あなたは常にビジネス言語から実装に関する言語に翻訳しようとしていますが、翻訳されていません。
典型的には、システムの実装に関してビジネスとのコミュニケーションを余儀なくされ、実装がビジネスと開発者がコミュニケーションの際に使用することを余儀なくされる「ユビキタス言語」になります。これには、さまざまな影響があります。ビジネスのドメイン エキスパートは、実装ドメインのエキスパートであると信じ始め、解決しようとしているビジネス ニーズではなく、実装の観点から機能を要求し始めます。
また、ほとんどのデータ駆動型の実装は、ドメインの「概念的な輪郭」に従っていないことがわかります。また、システムのコンポーネントは、問題を解決するために組み合わせる方法についてあまり柔軟ではありません。ビジネス モデルの概念と 1 対 1 でマッピングしないでください。コードがまとまっていない場合、変更や新機能によって実装全体の変更が必要になる場合があります。
ドメイン駆動設計は、実装をビジネス モデルに非常によく似たものにするためのツールを提供し、誰もがビジネスの言語を簡単に話せるようにします。実装をテストする「実行可能な仕様」を作成できますが、実際にはドメインの専門家が理解できます。