問題タブ [bounded-contexts]

イベント ソーシングを使用しているときに、2 つの境界付けられたコンテキストを最終的に一貫性を保つにはどうすればよいかという質問に対する答えを見つけています。あるコンテキストのエンティティから別のコンテキストの値オブジェクトにいくつかの値を複製した状況を意味します。値が変更されたときにドメイン イベントを使用して通知を取得できることはわかっていますが、これらの値を使用するイベント ストア内のすべての集計を更新する方法を教えてください。id 以外のプロパティでイベント ストアから集計をクエリするのは困難です。

例：

アイデンティティ コンテキスト:

• ユーザー (id、ユーザー名、パスワード、メール) - 集約ルート

議論の文脈:

• Author (id,userame) - 値オブジェクト (これらの値は Identity Context からのものです)
• Message (id, content, author ) - 集約ルート

DDD の学習を改善するために行った既存の C# WinForm ベースのシステムに基づいてドメインをモデル化しようとしているので、問題を単純化するために架空の概念モデルをまとめました。システム自体には、システムのあらゆる面で使用される Entity Framework オブジェクトに多数のロジックが混在する典型的なビジネス ドメインはありませんでした。Big Ball Of Mud (BBOM) だった気がします。

仕事でいくつかの DDD の概念に取り組みましたが、全体的な理解を深めたいと思っています。Evans の Blue Book「Domain-driven Design: Tackling Complexity in the Heart of Software」と Scott Millets の「Patterns, Principles and Practices of Domain-Driven Design」を読みました。このテーマに関する無数のビデオを見るだけでなく、Vaughn Vernon の記事も参照してください。何年にもわたってより多くのデータ駆動型開発を行ってきたので、これが浸透するのに時間がかかっていると感じています.

したがって、仮想システムは、私が行ったシステムに大まかに従う、製品を構築するための厳密な品質管理システムです。

概念モデルは次のとおりです。

これには 3 つの部分があります。必ずしも境界付けられたコンテキストではありませんが、これらの境界付けられたコンテキストがどこにあるかを特定するのに苦労しています。

ビジネス プロセスには 3 つの部分があります。

1. 製品の定義

このために、「ユーザー」は名前を含むさまざまな製品情報を入力します。この一環として、製品の厚さと素材を定義します。また、ビルダーが製品を構築するために使用する必要があるプロセスも定義します。また、目視検査と品質検査が必要かどうかも定義します。

2. ビルド製品

プロセスの一環として、「ビルダー」が製品を組み立てます。ただし、これはビルダーの資格に関してのみ制限されます。Builder は、厚さの範囲と材料に基づくプロセスに対して認定されているため、ビジネス ルールでは、プロセスの厚さの範囲と材料の間にある製品の厚さについて認定されている場合にのみ Builder を選択できます。

3. 検査

製品が構築されたら、検査することができます。この一環として、目視または品質検査のタイプが必要かどうかに応じて、最新の資格のある「検査員」が製品を検査できます。彼らは検査に合格するか不合格になります。

これらのプロセスの流れの一環として、製品のステータスが更新されます。これは次のようになります：

• 未組立
• 組み立てた
• 一部検査済み（2回の検査のうち1回検査済み）
• 合格した検査 (すべての検査が完了した)
• 失敗した検査 (すべての検査が失敗した)

以下は、考慮すべきドメイン外のシステムに関する情報です。

• システムは、検査を同時に入力できるマルチユーザーになるように設計されています
• 製品にデータが誤って入力された可能性があり、これを修正すると、入力されたビルドおよび検査データが無効になる可能性があります
• 入力されたデータは、さまざまなレポートで使用されます。

だから私はいくつかのアイデアが必要です：

1. 境界付きコンテキストが存在する場所。

2. 集約ルートをモデル化する方法 - どのデータをルートにする必要があり、どのエンティティ/値オブジェクトを含めるべきか。

   境界のあるコンテキスト内に必要なドメイン オブジェクトのデータのみを含めますか。つまり、ドメイン オブジェクトを完全にハイドレートしませんか。

3. プロセスのさまざまな部分でステータスを計算するために何かを実装する方法。

4. ドメイン データを正しく維持するために、データが誤って入力される可能性を処理する方法。

私はリポジトリの実装には興味がありません。純粋なドメインの概念だけに興味があります。

製品ステータスに関するデータの一貫性を保つために、複数のユーザーがデータを入力することに懸念があります。

午後全員

私は現在、ドメイン駆動設計 (DDD)を勉強していますが、基本的な概念を理解するのに苦労しています。

パターンの原則と実践 (Millett and Tune)

研究の過程で、ドメイン モデル (DM)という用語に出くわすことがよくありますが、一般的にさまざまなレベルの粒度で議論されています。

1. 場合によっては、相互接続されたさまざまなオブジェクト (顧客、販売、見積もり、請求書など) の成果物 (UML、スケッチ、写真) のコレクションとして表され、単一のサブドメイン内のすべての概念の概要が示されます。

   単一のサブドメインに対してモデルが 1 つしかないように

2. それ以外の場合は、 Productなどの単一のエンティティとして表され、サブドメインは多くの異なるドメイン モデルで構成されます。

上記のあいまいさにより、ドメインモデルが実際に何であるか、およびそのようなモデルを境界付けられたコンテキスト (BC)に配置する方法を理解するのに苦労しています。

これに加えて、ドメイン モデルは異なる境界付けられたコンテキスト間で共有できることを読みました。

たとえば、EmployeeはPayrollとHR Bounded Contextの間で共有されます

これを考慮して、

1. サブドメインを表すために複数のドメイン モデルを作成しますか?
2. または単一のものだけですか？
3. 後者の場合、そのような大規模なモデルをコンテキスト間でどのように共有しますか?

誰かがこのあいまいさを明らかにし、ドメイン モデルとは何か、それがどの程度細分化できるかを正確に説明してください。

とても有難い

ダニエル

DTO を使用してアプリケーションのユース ケースを公開する Application Service との境界付けられたコンテキストがあります。

境界付けられたコンテキストには、豊富なドメイン オブジェクトを使用してドメイン ユース ケースを公開するドメイン サービスも含まれます。アプリケーション サービスは、ドメイン サービスの「クライアント」です。

最後に、ドメイン オブジェクトの永続性を可能にするリポジトリです。

ドメインには他の境界付けられたコンテキストが存在し、境界付けられたコンテキストを所有するチーム間の関係は顧客/サプライヤーであるため、チームは同じ目標に合わせて協力し、必要なユースケースを他の境界付けられたコンテキストに公開することができます。

この状況では、「顧客の境界付けられたコンテキスト」は「サプライヤーの境界付けられたコンテキスト」に接続する必要がありますか?

「サプライヤーの境界付けられたコンテキスト」が、「サプライヤーの境界付けられたコンテキスト」の豊富なドメイン オブジェクトを公開しているリポジトリまたはドメイン サービスに直接アクセスしても問題ありませんか? (「サプライヤーの境界付けられたコンテキスト」をドメイン内でのリークから保護する「顧客の境界付けられたコンテキスト」の ACL を使用)。ドメインのリファクタリングによってすべての ACL が壊れ、メンテナンスが必要になるため、このアプローチが適切かどうかはわかりません。これがACLの目標であることは知っていますが...

それとも、「コンシューマー バウンド コンテキスト」は、パブリック DTO が公開されている「サプライヤー バウンド コンテキスト」のアプリケーション サービスにのみ接続することが望ましいでしょうか。(ACL は必要ありません)。ユースケースが明らかにドメインのユースケースであっても、アプリケーションサービスがドメインサービスを模倣してアクセスポイントとして機能するように強制するため、このアプローチが良いかどうかはわかりません.

ご意見はありますか？良い/悪い経験を持つ2つのアプローチのいずれかを試した人はいますか?

Vaughn Vernon の本や Scott Millett の本からは明確な答えが見つかりません。

アプリケーションの特定のディレクトリ構造に関するフィードバックを探しています。これは、「正解」などがある古典的なスタック オーバーフロー形式に従っていないことに気付きますが、それでも興味深いと思います。有意義なフィードバックを提供するには、まずいくつかのコンテキストを理解する必要があります。

--

私の 2 人の同僚と私は、Clean Architectureを使用するアプリケーションを作成しました。ルートへの HTTP リクエストはリクエスト モデルに変換され、ユース ケースに渡され、プレゼンターに渡されるレスポンス モデルが吐き出されます。

コードは完全にオープン ソースであり、GitHubで見つけることができます。また、主要なディレクトリの内容を説明するドキュメントもいくつかあります。

私たちはコードの再編成を考えており、これまでに思いついたことについてフィードバックを得たいと考えています。この再編成の主な理由は次のとおりです。

• 今のところ、ドメインの一部ではないものを配置するのに適した場所がありませんが、何らかの形でそれにバインドされています。たとえば、寄付 ID を認識している承認コード (承認はコア ドメインの一部ではありませんが、寄付 ID は含まれています)。

• まとまりのあるものをグループ化するのはいいことです。寄付コードとメンバーシップ アプリケーション コードはまとまりがありますが、両者は相互に依存していません。これは、ドメイン駆動設計における境界付きコンテキストの概念と密接に関連しています。現在、これらのコンテキストはコードで明示的に表示されていないため、特にドメインに慣れていない場合は、相互に依存させるのは簡単です。

これらは、これまでに特定したコンテキストです。これは予備的なリストであり、アイデアを提供するためのものであり、私がフィードバックを求めている部分ではありません.

• 寄付
• メンバーシップ
• フォーム サポート (電子メールの検証、IBAN の生成など)

私がフィードバックを求めているのは、次のように切り替えることを検討しているディレクトリ構造です。

コンテキストのAuthorization/すぐ内側にあるフォルダは、現在インフラストラクチャに配置されている承認コードのホームを提供します。私たちのドメインの一部ではないが、まだそれにバインドされている他のコードは、コンテキスト フォルダーに直接入ることができ、その中にまとまりのある/関連するもの (承認など) がある場合は、独自のフォルダーを取得します。

有益なフィードバックを提供するために必要な追加情報を提供させていただきます。

さまざまな境界付けられたコンテキストを処理するために、複数の Maven モジュールによるソリューションを開発しています。

スプリング ブートのおかげで、各モジュールは独自の REST API を公開し、それらはすべて @SpringBootApplication によって注釈が付けられたクラスを持つ 1 つの Maven モジュールでホストされます。単純化されたプロジェクト構造は次のようになります。

複合UIに直面するときに同じパターンを使用しようとしました:レイアウト、静的リソースを保持する1つの場所、その間、htmlページは、そのmavenモジュールに保持されている各境界付きコンテキストに属します.

問題は、スプリング ブート ドキュメントで見つけたように、他の jar ファイルから静的リソースを提供する方法がないことです。

この機能を取得するための解決策はありますか、またはここにアーキテクチャ上の間違いはありますか? または春の外側の何か（オーバーレイなど）が解決策ですか？