17

おそらく同様の質問が何度も寄せられていますが、すべての回答が DDD の理解を深めるのに役立つと思います。私が DDD の特定の側面をどのように認識しているかを説明したいと思います。私はそれについていくつかの基本的な不確実性を持っています. これらの質問は、DDD への「古典的な」アプローチを想定していることに注意してください。これは、ORM などを使用することを意味します。CQRS やイベント ソーシングなどのアプローチは、ここでは考慮されません。

  1. 集合体とエンティティは、ドメイン ロジックを実装する主要なオブジェクトです。それらには状態とアイデンティティがあります。このコンテキストでは、ドメイン ロジックを、その状態を変更するすべてのコマンドのセットと認識しています。それは理にかなっていますか？ドメイン ロジックが状態のみに関連するのはなぜですか? ID や状態を持たないドメイン オブジェクトをモデル化することは合法ですか? ドメイン オブジェクトをトランザクション スクリプトとして実装できないのはなぜですか? 例: 出会い系サイトのパートナーを推薦するオブジェクトを考えてみましょう。そのオブジェクトには実際の状態はありませんが、かなり多くのドメイン ロジックを実行しますか? それをサービス層に入れるということは、ドメイン モデルがすべてのロジックをカバーできないことを意味します。

  2. 他のドメイン オブジェクトへのアクセス。アグリゲートはリポジトリにアクセスできますか? 例: (ステートフル) ドメイン オブジェクトが作業を実行するためにシステムのすべての「ユーザー」にアクセスする必要がある場合、リポジトリを介してそれらにアクセスする必要があります。結果として、ORM はオブジェクトをロードするときにリポジトリを注入する必要があります (これは技術的に難しいかもしれません)。オブジェクトがリポジトリにアクセスできない場合、この例のドメイン ロジックをどこに配置しますか? サービス層で？サービス層にはロジックがないと思われますか?

  3. 集合体とエンティティは外の世界と対話するべきではなく、境界のあるコンテキストのみに関心があります。外部の依存関係 (IPaymentGateway や IEmailService など) をドメイン オブジェクトに挿入しないでください。これにより、ドメインが外部からの例外を処理することになります。解決策: イベントベースのアプローチ。では、どのようにイベントを送信しますか? ドメイン オブジェクトをインスタンス化するたびに、正しい「リスナー」を注入する必要があります。ORM は「データ」の復元に関するものですが、主に依存関係を注入することを目的としていません。DI-ORM ミックスが必要ですか?

  4. ドメイン オブジェクトと DTO。集約ルートの状態を照会すると、その状態 (DTO) の射影またはドメイン オブジェクト自体が返されますか? 私が見るほとんどのモデルでは、クライアントはドメイン データ モデルに完全にアクセスでき、ドメインの実際の構造に深い結合が導入されます。集計の背後にある「オブジェクト グラフ」は、それ自体がビジネスであると認識しています。それはカプセル化ですよね？したがって、私にとっては、集約ルートは DTO のみを返す必要があります。多くの場合、DTO はサービス層で定義されますが、私のアプローチはドメイン自体でモデル化することです。サービス層はさらに別のレベルの抽象化を追加する可能性がありますが、それは別の選択です。それは良いアドバイスですか？

  5. リポジトリは、集約ルート レベルですべての CRUD 操作を処理します。他のクエリはどうですか？クエリは、ドメイン オブジェクトではなく DTO を返します。それが機能するためには、レポジトリは結合を導入するドメインのデータ構造を認識している必要があります。私のアドバイスは以前と似ています: イベントを使用してビューにデータを入力します。したがって、内部構造は公開されず、ビューを構築するために必要なデータを運ぶのはイベントだけです。

  6. 作業単位。システム境界のコントローラーは、コマンドをインスタンス化し、それらをサービス レイヤーに渡します。サービス レイヤーは、適切な集約をロードして、コマンドを転送します。コントローラーは、複数のコマンドを使用して複数のサービスに渡す場合があります。これはすべて、作業単位パターンによって制御されます。つまり、リポジトリ、エンティティ、サービス - すべてが同じトランザクションに参加します。同意しますか？

  7. ビジネスロジックはドメインロジックではありません。ビジネスの観点からすると、ユース ケースの実現には、顧客の登録、電子メールの送信、ストレージ アカウントの作成など、多くの手順が含まれる場合があります。この全体的なプロセスは、ドメインの集約ルートに収まりきらないほどです。ドメイン オブジェクトは、あらゆる種類のインフラストラクチャにアクセスできる必要があります。解決策: ワークフローまたはサガ (またはトランザクション スクリプト)。それは良いアドバイスですか？

ありがとうございました

4

2 に答える 2

7

私が提案できる最初のベスト プラクティスは、Evans の本を読むことです。二回。
あまりにも多くの "DDD プロジェクト" が失敗するのは、開発者が DDD は単に OOP が正しく行われているだけだと偽っているからです。

次に、DDD は非常に複雑なビジネス ルールを正しく処理する必要があるアプリケーション向けであることを理解する必要があります。一言で言えば、ビジネスを理解するためにドメインの専門家にお金を払う必要がないのであれば、DDD は必要ありません。実際、DDD の中心的な概念は、コーダー、専門家、およびユーザーの両方がお互いを理解するために共有するユビキタス言語です。

さらに、 Vernon による効果的な集計設計を読んで、集計とは何か (一貫性の境界) を読んで理解する必要があります。

最後に、ここに記載されているモデリング パターンが役立つ場合があります。

于 2013-08-14T09:57:49.880 に答える
6

上記の私のコメントにもかかわらず、私はあなたのポイントを突き刺しました. (注: 私はエリック・エヴァンスでもジミー・ニルソンでもないので、私の「アドバイス」は控えめに聞いてください)。

  1. あなたの例「出会い系サイトのパートナーを推薦するオブジェクトを検討してください。」は、ドメイン サービス (インフラストラクチャ サービスではありません) に属します。こちらの記事を参照してください - http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

  2. 集約はリポジトリに直接アクセスしませんが、複数のドメイン オブジェクトからの操作を 1 つに結合する作業単位を作成できます。

  3. これについてはわかりません。これは本当にそれ自体が問題になるはずです。

  4. これには議論の余地があります。理論的には、ドメイン エンティティは集約ルートの外部で直接利用できるわけではありませんが、それが常に実用的であるとは限りません。この決定はケースバイケースで検討します。

  5. 「クエリ」の正確な意味がわかりません。ドメインで考えられるすべての "読み取り" シナリオをモデル化することが実用的ではない、または十分なパフォーマンスが得られない場合は、CQRS ソリューションがおそらく最適であることを示唆しています。

  6. はい私は同意する。UOW は、さまざまなレイヤーで使用できるツールボックスのツールです。

  7. このステートメントは、「ビジネス ロジックはドメイン ロジックではない」という根本的な誤りです。ドメインは表現のビジネス ロジックであるため、使用する理由の 1 つubiquitous languageです。

于 2013-08-13T20:26:19.997 に答える