0

私はドメイン駆動設計 (DDD) の手法を試していますが、まだよく理解していないように感じています。

DDDは、ドメインオブジェクト、永続化のためのリポジトリ、クライアント（プレゼンテーション）用のドメインオブジェクトを組み立てるためのアグリゲータ、ドメインオブジェクトとリポジトリの上の薄い層であるサービス、アグリゲータにビジネスロジック（永続性、セキュリティなどのインフラストラクチャのものではない）を置くことを提案していますトランザクション境界として機能します。

このように言いましょう：

DDD では、ViewController --> SomeService --> {Domain Objects, Repositories, Aggregators}

私の現在の（手続き​​型）アプローチでは：ViewController --> SomeService --> DAO/Repository

ここで、ViewController は 1 つ以上のサービスと通信して、DAO を使用してデータベースとの間でデータをプル/プッシュします。ドメイン オブジェクトのプロパティでのみ動作するビジネス ロジックが、そのドメイン オブジェクト自体のメソッド内にある場合。最後に、サービスから取得したデータは DTO に集約され、View Layer に表示されます。

したがって、私には両方のアプローチがほとんど同じように見えます。

誰かが私に欠けているものを説明できますか?

PS：質問をよりよく説明するために、さらに情報を追加しています。理論的には、誰もが DDD が「ロジックはドメイン オブジェクトにある必要がある」ことを示唆していると言っています。わかった。実際のシナリオを考えてみましょう。

ShoppingCart アプリケーションで、一部のユーザーが注文を出しました。注文を処理するには、次のすべてのサブタスクを実行する必要があります。

  1. 各アイテムの詳細を取得し、合計注文価格を計算します。

  2. 配送先住所を取得し、住所確認サービスを使用して確認します

  3. クレジットカードの詳細を検証/認証する

  4. すべての注文関連情報を DB に保存します

したがって、DDDに従って、ロジックを配置します。

  1. List オブジェクトをループする Order オブジェクトでの Order Total 計算。

  2. Address オブジェクトには、BING アドレス検証を呼び出す validate() メソッドがあります。

  3. CreditCard クラスには、いくつかの CCAuthorizationService を呼び出してサードパーティのサービスを使用して承認する authorize() メソッドがあります。

  4. いくつかのリポジトリを使用して、すべての注文内容を DB に保存します。

これらのすべてのステップは、 Order.process() を呼び出すことによってトリガーされます

これが正しい DDD アプローチである場合は? もしそうなら、私たちのドメインオブジェクトはリポジトリと直接やり取りしており、これは関心の分離に違反しているようです.

これが正しい DDD アプローチではない場合、上記のユースケースをどのように設計するのか教えてもらえますか?

4

4 に答える 4

1

要するに、ロジックが存在する場所です。DDD では、ロジックは主にモデル レイヤーに入り、データの近くにとどまります。手続き型コードでは、ロジックはトランザクション レイヤーに入り、データから分離されます。Fowler には、ここで読むことができる優れた説明があります。

于 2012-08-10T17:33:13.237 に答える
1

DDD は言語に依存しません。専門家を通じてドメインを理解し、ドメインについて話すための共通言語を構築することです。そのため、関数型、手続き型、またはオブジェクト指向のプログラミング言語と直接比較することはできません。比較できないからです。

ビュー コントローラーは MVC フレームワークに固有であり、DDD に固有ではありません。

MVC では、ビューのデータを準備するための DTO はビュー モデルになります。

これが役立つことを願っています。

于 2012-08-13T08:02:57.813 に答える
0

テクノロジーやOOPなどではありません。それは、手元のドメイン、ドメインの専門家が使用する言語に焦点を当て、ドメインを理解し、重要な概念がコードに存在するようにそのドメインをモデル化することです。

もともとはOOPを使用して行われ、多くの人がOOPを使用してのみ実行できると主張していました。ただし、最近、Greg Youngのような人々は、関数型言語でDDDを実行する方法を示し、それでもドメインに焦点を合わせ続けています。

手続き型コードはそれをすべて無視する傾向があり、データソースが何であれ、データの読み取り/書き込み方法に焦点を当てるだけです。たとえば、Movexのようなシステムと統合すると、TAXEM.YAROOD FOOB.AARのような完全に遅延した名前のテーブルと列が10億個あり、そのコードを読んでいる人には意味がありません...

于 2012-08-13T07:39:20.990 に答える
0

それらは似ています。

「OOP」と「DDD」を実際に比較していることを願っています。DDD は OOP (IMO) のサブセットであるか、少なくとも OOPL に含まれている必要があります。DDD は、責任の分割に関する具体的な考え方です。

于 2012-08-10T17:22:19.920 に答える