4

ドメイン駆動設計を実践しようとしていますが、コードの基本構造には次のオブジェクトが含まれています。

Action->Facade->
Service
Model
Repository

次のように、CRUD メソッドをモデルのどこに配置する必要があると思いますか。

order.save(new order())

または、次のようにファサードに配置します。

addOrderFacade.save(new order())
4

3 に答える 3

7

「保存」または「削除」メソッドは、リポジトリに属します。通常、Save はサービスまたはコマンド ハンドラーによって呼び出されます (コマンド ベースのアプローチを使用してドメインを更新している場合)。Save は CRUD から CU を処理し、D は独自のメソッドを取得します。R の部分は興味深いものです。

R がそれを更新するために 'GetEntity' を意味する場合、保存と同じ場所で処理されるドメイン リポジトリ (複数のリポジトリがあります) の一部にすることができます。

ただし、基本的にユーザーに結果を返すクエリのみを表示するために読み取りたい場合は、クエリ専用の別のリポジトリと、単純化された読み取り専用モデルを使用する必要があります。このレポは、コントローラーまたは UI からも呼び出すことができます。

于 2012-06-14T06:35:46.813 に答える
2

それらをドメインクラスに入れないことをお勧めします。

ドメイン クラス パッケージは、DAO レイヤーが異なる他のアプリのどこかで再利用できます。そのため、DAO のモデルの上に別のレイヤーを作成することをお勧めします。

于 2012-06-14T04:35:13.913 に答える
1

慣例では、CRUDメソッドをモデルではなくリポジトリまたはサービスレイヤーに配置します。実際、SpringやHibernateのようなフレームワークを使用する場合は、このアプローチを使用するように誘惑されます。その理由だけで、通常は簡単です。

  • 他の開発者はそれを期待しています
  • フレームワークはそれをサポートします
  • チュートリアルと例はそれを前提としています

ただし、設計の観点からは、このアプローチに反対する強い主張があります。それは貧血のドメインモデル、言い換えれば、状態のみを持ち、振る舞い（構造体）を持たないオブジェクトにつながりますが、公平に言えば、オブジェクト指向ではありません。ビュー、コントローラー、サービス、リポジトリの各レイヤーを介して多くのデータを渡す必要があり、状態と動作をまとめるには多くの「オーバーヘッド」コードが必要です。正規のモデルレイヤーに注意を払わないと、チーム間でモデルの不一致や断片化が発生する可能性もあります。

この設計の落とし穴を回避しようとするアプローチは、ドメイン駆動設計と呼ばれることが多く、EricEvansによってそのように定義されています。ウィキペディアのページから、DDD内にサービスとリポジトリの場所がまだあることに注意してください。

  • サービス：操作が概念的にどのオブジェクトにも属していない場合。問題の自然な輪郭に従って、これらの操作をサービスに実装できます。サービスの概念は、GRASPでは「純粋な製造」と呼ばれています。
  • リポジトリ：ドメインオブジェクトを取得するためのメソッドは、代替のストレージ実装を簡単に交換できるように、専用のリポジトリオブジェクトに委任する必要があります。
  • ファクトリ：ドメインオブジェクトを作成するためのメソッドは、代替の実装を簡単に交換できるように、専用のファクトリオブジェクトに委任する必要があります。

興味がある場合は、DDDおよび（すぐ下の）DDDサンプルアプリケーションをサポートするソフトウェアツールを確認してください。

于 2012-06-14T07:21:04.590 に答える