データベース駆動型開発をいつ使用する必要があるか、ドメイン駆動型開発をいつ使用する必要があるかについて、誰でも良い答えを得ることができますか? これらの両方の開発アプローチは、それぞれの分野で重要です。しかし、どのような状況でどのアプローチが適切であるかは明確ではありません。推奨事項はありますか？
13233 次
6 に答える
47
まず、背景として、Martin Fowler は彼の著書 Patterns of Enterprise Architecture で 3 つの異なる「パターン」について実際に説明しています。トランザクション スクリプト、アクティブ レコード、およびドメイン モデル。DDD では、アーキテクチャ全体にドメイン モデル パターンを使用し、このモデルを実装および設計するための多くのプラクティスとパターンについて説明しています。
トランザクション スクリプトは、階層化されていないアーキテクチャです。同じコードがデータベースの読み取り/書き込み、データの処理、およびユーザー インターフェイスの処理を行います。
Active Record はその一歩先です。UI を分割すると、ビジネス ロジックとデータ レイヤーは、データベースをモデルにしたアクティブなレコード オブジェクトに共存します。
ドメイン モデルは、モデル内に存在するビジネス ロジックをデータ層から切り離します。モデルはデータベースについて何も知りません。
ここで、興味深い部分に到達し
ます。この追加された分離のコストは、もちろん追加の作業です。利点は、保守性と柔軟性が向上することです。
トランザクション スクリプトは、ビジネス ルールがほとんどまたはまったくない場合、データ入力のみを行い、検証手順がない場合、またはすべての検証がデータベースに実装されている場合に適しています。
アクティブ レコードはそれにある程度の柔軟性を追加します。たとえば、アプリケーション間でその下のレイヤーを再利用できる UI を分離するため、いくつかのビジネス ルールと検証ロジックをビジネス オブジェクトに簡単に追加できます。しかし、これらは依然としてデータベースと密接に結びついているため、データモデルの変更には非常にコストがかかる可能性があります。
ビジネス ロジックをデータベースから分離する場合は、ドメイン モデルを使用します。これにより、変化する要件を簡単に処理できます。ドメイン駆動設計は、この追加された柔軟性を最適に使用して、データベースの実装に縛られることなく複雑なソリューションを実装する方法です。
多くのツールにより、データ駆動型のソリューションがより簡単になります。マイクロソフトの分野では、すべてのコードが Web ページのすぐ後ろにある Web サイトを視覚的に設計するのは非常に簡単です。これは典型的なトランザクション スクリプト ソリューションであり、単純なアプリケーションを簡単に作成するのに最適です。Ruby on Rails には、アクティブなレコード オブジェクトの操作を容易にするツールがあります。これは、より単純なソリューションを開発する必要がある場合に、データ駆動型に移行する理由になる可能性があります。データよりも動作が重要で、事前にすべての動作を定義するのが難しいアプリケーションでは、DDD が最適です。
于 2008-11-21T12:49:08.600 に答える
7
同様の質問をしました: O/R マッピングを使用する場合、どこから設計を開始しますか? オブジェクトまたはデータベース テーブル?
私が得た回答から、データベース駆動型開発を使用する具体的な理由がない限り、ドメイン駆動型開発を使用してください。
于 2008-11-21T12:50:34.120 に答える
7
このように考えてください。
問題のドメインは永遠に存在します。クラス定義は、ドメインの永遠の特徴を反映します。
リレーショナル データベースは、現在好まれている持続性メカニズムです。ある時点で、これを超えて、「より新しい」、「より良い」、「異なる」ものに移行します。データベースの設計は 1 つの実装にすぎません。それは、問題のドメインよりもソリューション アーキテクチャを反映しています。
したがって、それはドメインファーストです。クラスは、問題の領域と普遍的な真実を反映しています。リレーショナル データベースと ORM は 2 番目と 3 番目です。最後に、モデルの周りに他のものを埋めます。
于 2008-11-21T12:59:50.090 に答える
2
mendelt の投稿の補足として、私は 4 番目のパターンがあると思います: 階層化され、ビジネス ロジックを永続性とストレージから分離し、「エンティティ」または「ビジネス オブジェクト」を使用しないパターンです。必要に応じて、トランザクション/アクション スクリプトと DDD の中間点です。
私が取り組んできた多くのシステムでは、永続層 (リポジトリ) が SqlClient を直接使用し、データセットを呼び出し元のサービスに返しました。サービスは、コントローラーを介してユーザーに送信される決定とコンパイルされたビューを実行しました。サービス レイヤーをビジネス モデルと考えるかもしれませんが、そのとおりですが、それは DDD の意味での「ドメイン」モデルではありませんでした。それでも、すべてのビジネス ロジックはその 1 つのレイヤー、期間で発生しました。各レイヤーにはそれぞれの役割がありました。ビューはデータを表示し、コントローラーはビューを決定し、パーシスタンス レイヤーはストレージを処理し、サービスはコントローラーとパーシスタンスの間で機能しました。
要点は次のとおりです。DDD は、Ul、テスト、およびコードを通じてビジネスを定義するアプローチです。エンティティ、値オブジェクト、および集計についてではありません。これらは、DDD に対する OOP 純粋主義者のアプローチの副産物にすぎません。
あなたの考慮のためのより多くの考え。
于 2011-11-15T04:56:30.373 に答える
1
複雑なビジネス モデルの場合、ActiveRecord と DDD の組み合わせを好みます。ドメイン オブジェクトは自分自身を保存する方法を知っており、データ アクションはリポジトリに対して実行されます (リポジトリをコレクションとしてモデルにデータを公開するものと見なす場合、nHibernate は汎用リポジトリとして機能します)。ビジネス ロジックはドメイン エンティティに常駐し、ビジネス ニーズがある場合にのみ、値の型のカプセル化を行うこともできます。DDD の一部の実装では、すべてのパブリック セッターを削除し、メソッドを介してエンティティのみを変更することを好みます。非常に優れたビジネス上のニーズがない限り、私はその実装のファンではありません。
この実装により、ActiveRecord の使いやすさと DDD のビジネス ロジックのカプセル化が実現するように思えます。
于 2012-08-20T15:49:48.700 に答える
0
ドメイン駆動開発は確実に進むべき道です。それはより理にかなっていて、柔軟性を追加します。
于 2010-09-27T23:46:49.590 に答える