問題タブ [bounded-contexts]

私はDDDの概念に比較的慣れていないため、比較的単純なシナリオで境界付けられたコンテキストを定義する方法を説明する例がたくさんあることに気づきましたが、カバーされていないように見える領域の1つは、マスターデータと参照データです.

ここで言及している参照データの種類は、通貨コード、国コード、および測定単位であり、有効な値のみが使用されるようにするために使用されます。

私が言及しているマスター データの種類は、顧客や製品などのエンティティであり、異なる境界付けられたコンテキストがエンティティの独自の視点を持つ必要はありません。一部のシナリオでは、請求の境界付けられたコンテキストの顧客エンティティは、出荷の境界付けられたコンテキストの顧客エンティティとは異なることを理解していますが、この質問の目的のために、請求と発送の両方にまったく同じ顧客データが必要であると想定できます。

私の質問は、複数の境界付けられたコンテキスト (ERP システムなど) を持つアプリケーションで、マスター データと参照データを共通の境界付けられたコンテキストで定義するか、まったく同じデータが含まれている場合でも、これらのエンティティを各境界付けられたコンテキストで複製する必要があります。 ?

ドメイン駆動設計のマルチ境界コンテキスト原則を適用し、データベース内の同じテーブルを指す 3 つの異なるオブジェクト (3 つの異なるドメイン コンテキスト内) を持っています。ジュリー・ラーマンが示唆したように、私はすべてのオブジェクトを持つ共有データベース モデルを持っています。この共有データベース モデルは、コード ファーストの移行に使用されます。また、共有データベース モデルの外部キー リレーションシップと列の制約を表す流暢な API 構成もあります。問題は、3 つのドメイン固有のコンテキストにこれらの流暢な API 構成を知らせる必要があるかどうかです。これらの各コンテキストでオブジェクト グラフを検証したいと思います。これらの個別のドメイン コンテキストで必要な文字列の長さなどについて心配する必要がありますか? 3 つの個別のドメイン コンテキストのそれぞれでこれらの関係を構成する必要がありますか?

複数の境界付けられたコンテキストからのデータ統合にデータベース ビューを使用することに問題はありますか? 私の考えでは、データベース ビューがデータの構造/詳細をカプセル化しているため、RPC 呼び出しを行うのと同じことです。

したがって、私の読み取り側からは、複数の境界付けられたコンテキストからデータベース ビューを連携させて、UI 画面の要件を満たすことができます。それらは密結合ですか、そうですが、少なくとも私の理解では、これは Udi Dahan が IT/Ops サービスと呼んでいるものと非常によく似ています。

考え？

ユーザーがサービスへの支払いを可能にする特定のドメインでは、支払い承認は不可欠な部分ですが、技術的には、支払い承認は、いくつかの前提条件と渡された情報に基づいて支払いを承認するスタンドアロン コンポーネントとして設計できます。

このような場合、支払い承認はサブドメイン (サポート ドメイン) にするか、支払いサブドメインの境界付きコンテキストにする必要があります。

Doctrine 2 を使用して、異なる境界付けられたコンテキストからの 2 つのエンティティ間の関連付けマッピングを実装する正しい方法を理解するのに苦労しています。「User」および「Content」境界付けられたコンテキストにそれぞれ属する 2 つの「User」および「Post」エンティティがあるとします。 . 多対一の関連付けを通じて「投稿」の作成者を決定する「コンテンツ」コンテキストには、「ユーザー」の概念もあります。したがって、「コンテンツ」コンテキストの「ユーザー」は、ユーザー ID を含む単なる値オブジェクトです。

私の質問は、Doctrine 2 を使用してこの関連付けをどのように実装すればよいですか? どちらにも独自の問題がある2つのソリューションがあります。

解決策 1 :

解決策 2 :

最初のソリューションでは、「ユーザー」コンテキストの「ユーザー」エンティティが「コンテンツ」コンテキスト内で使用されており、BC が互いに独立しているという DDD ルールに違反しています。2 番目の解決策は、DDD ルールを尊重しますが、データベース スキーマに影響を与えます (外部キー制約により、"users" テーブルと "posts" テーブルの間のデータベース レベルの関係を削除します)。

では、そのような関連付けを実装する正しい方法は何でしょうか?

dddと境界付けられたコンテキストについて質問があります。

2 つの境界付けられたコンテキストがあるとします。最初のものでは、集約ルートは Web ページに広告を公開できる Customer です。私はそれが彼の振る舞いに当てはまると思います。彼は PublishAdvertisement() のメソッドを持っています。しかし、2 番目の境界付けられたコンテキストには、Advertisement が集約されています。これは、Advertisement が Customer に属しているという性質上、Customer プロパティを持っていることを意味します。

Customer と Advertisement はどちらも、システムとデータベースで一意です。

私の質問は次のとおりです。顧客からの広告の作成をファクトリまたは依存性注入に委任することをお勧めしますか?

編集：

回答ありがとうございます 情報不足で申し訳ありません。

依存性注入:

特定の状況を解決するための最良の方法は何だろうと思っていました。会社には広告テンプレートの在庫があります。テンプレートが在庫にあれば使用できますが、そうでない場合は誰かにレンタルされます。同社は、より多くの株式を保有する計画を持っています。顧客がこれらのテンプレートで広告を作成したい場合は、テンプレートを選択し、在庫があればすべて準備完了です。これをそのまま読んで、サービス（ドメイン）CheckAvailability（テンプレート）が必要であると想定しました。サービスの性質上、検証でいくつかの集計を使用し、データベースにクエリを実行するため、特定の集計には適合しません。将来、より多くの Stocks (他の会社から借りたもの、おそらく他の誰かのデータベース) が存在するようになると、依存性注入を使用して、実装を変更せずにこれらの Stocks をサービスに追加することを計画していました。

制限されたコンテキスト:

境界付けられたコンテキストとデータベースに関して。はい、1 つのデータベース オブジェクトと、同じデータベース オブジェクトを使用する 2 つのコンテキストがあります。Order には Customer への参照があり、Customer に属しているため、次のようになります。

Order() 顧客 顧客 (get; プライベート セット;)

///その他のプロパティとメソッド

これらのような 2 つのコンテキスト (Customer->Order___1:M) が同じデータベースに関連しているという意味で、リンク、ビデオ、本を介して追加情報をいただければ幸いです。ありがとうございました。

私は現在 DDD について読んでいますが、この質問に対する答えを見つけることができませんでした。複数の境界付けられたコンテキストを持つ大規模なアプリケーションがある場合、私が知る限り、各 BC は個別のアプリケーションであるため実装する必要があります。したがって、各 BC には独自の UI とイベント ストレージがあるという結論に達するのは論理的です。いくつかの記事 (CQRS について) によると、イベント ストレージは単一の信頼できる情報源であるため、以前は単一のイベント ストレージしかないと考えていました。これらのステートメントの唯一の問題は、コンテキストが不足しているということです。では、イベント ストレージは、単一の境界付けられたコンテキストまたはアプリケーション全体における唯一の信頼できる情報源でしょうか?