4

ギャンブラーが賭けのポートフォリオを維持し、時間の経過に伴う利益/損失を追跡できるようにするクライアント用のシステムを構築したとします。このシステムは、さまざまなスポーツへの賭け、勝利を他の賭けにロールオーバーするなど、多くの複雑なドメイン ロジックをサポートしています。

次に、私のクライアントは、予想屋のアイデアをサポートしたいと考えています。予想屋は実際にギャンブルをするのではなく、何を賭けるべきかについてのヒントである「予想シート」を作成します。チップ シートにはさまざまな種類があります。ベット可能なイベントに関するチップを含むものもあれば、競馬に関するチップのみを提供するものもあります。私のクライアントは、システムがギャンブラーのパフォーマンスを追跡するのと同じ方法で予想屋のパフォーマンスを追跡することを望んでいます。さらに、さまざまな種類の予想屋内および異なる種類の予想屋の間でパフォーマンスを比較できるようにします (たとえば、最高の競馬予想屋は誰ですか?彼らは一般的にサッカーの予想屋よりも優れたパフォーマンスを発揮しますか?)

現在、ドメイン言語はギャンブラーと予想屋の間で完全に異なり、ギャンブラーのポートフォリオには存在しない予想シートの追加の分類があります。これは、これらが別個の境界付けられたコンテキストであることを示唆しています。ただし、どちらも時間の経過とともにパフォーマンスを追跡するため、多くの共有ロジックがあります。

だから私の質問は：

  1. これらは本当に別個の境界付けられたコンテキストですか? 私は、ギャンブラーのコンテキストに分類を追加することに慎重です (滑りやすい坂道のように感じます)。
  2. それらが異なるコンテキストである場合、次のことを行う必要があります。
    • それらの間でパフォーマンス追跡ロジックを共有しますか (つまり、DLL、jar などを共有しますか)? これにより、コンテキスト間の緊密な実装結合が作成され、正しくないと感じられます。
    • パフォーマンス追跡ロジックをギャンブル境界コンテキストに残し、分類ロジックを予想屋バウンダー コンテキストに配置し、ギャンブル コンテキストにパフォーマンス追跡を依頼しますか? この場合、予想屋のコンテキストがギャンブルのコンテキストにコマンドを送信するように見えますが、これも間違っているように感じます (私はイベントの方が快適です)。
    • 何か他のことを...両方のコンテキスト間で通信し、相互に関連付けるある種の合成レイヤーを行いますか?

明確化

ギャンブラーのポートフォリオと予想屋の予想シートはほとんど同じです。唯一の違いは、予想シートを分類できることです (例: 競馬、サッカーなど)。

パフォーマンス追跡とは、ポートフォリオ/ヒントシートの利益/損失を測定することです。

4

4 に答える 4

3

  1. 2 つの明確に異なるモデルがあり、技術的な重複のみがある場合は、BC が 2 つあることに同意します。ただし、複数の BC を持つことは、特に通信が必要な場合に、少し「費用がかかる」ことに注意してください。モジュールを使用する方がはるかに「安価」です。そのため、複数の BC を持つことを軽視すべきではありません。

  2. 青本、第 4 部 (戦略設計)、第 15 章 (蒸留) では、シナリオにうまく適合する汎用サブドメインの概念が紹介されています。パフォーマンス計算は、モデルの全体的な機能に不可欠ですが、2 つの BC で使用できるライブラリに分離できるため、一般的なサブドメインと見なすことができます。これは、モデルを抽出し、技術的な問題を抽象化するためのパターンです。複雑なメッセージングや BC 間の RPC 通信を実装する必要はありません。意図を明らかにするインターフェイスを備えた共有ライブラリを使用するだけです。

于 2012-10-26T16:26:11.537 に答える
2

これは明らかに (少なくとも) 2 つの境界付けられたコンテキスト (BC) のケースであり、それらが異なるドメイン言語を持っているという事実が最大の手がかりです。

私の理解が正しければ、パフォーマンス トラッキングはドメインの概念であり、おそらく BC そのものであるはずです。共通の追跡と特定の追跡 (予想屋向け) のインターフェースを定義できます (共通のインターフェースの種類のプロジェクトで)。これは、他の BC のエンティティによって実装されます。したがって、PerformanceTracking BC は具体的なギャンブラーや予想屋には関心がなく、他の BC は特定のパフォーマンス トラッカーに結合されません。

はい、BC を同期する必要があり、ドメイン イベントはまさにその目的のためのものです。厳密には単純ではありませんが、慎重に行えばそれほど複雑ではなく、疎結合コードの大きな利点が得られます。

于 2012-10-28T08:13:34.047 に答える
1

それらは2つの異なる文脈だと思いますが、あなたもそう思いますよね?

個人的には、ギャンブル コンテキストのドメイン イベントを使用して、パフォーマンス追跡情報を生成します。コードはまだ疎結合です (ロジックはドメイン イベントに依存するだけなので)。

もちろん、これらのjar/dllのいずれにも属さないアダプターを間に作成することもできます。つまり、コンテキスト 1 のドメイン イベントにサブスクライブし、情報を適応させてから、コンテキスト 2 でスタッフを呼び出すものです。このようにして、コンテキスト間で 100% の透過性が得られます。

于 2012-10-26T14:26:59.747 に答える
1

パフォーマンス トラッキングは、彼自身が Bounded Context のように聞こえるというマイクの意見に、私はおそらく同意するでしょう。これは、より明白な境界のように見えます。

Betters と Tipsters は、同じ境界付けられたコンテキストまたは異なる境界付けられたコンテキストの異なる集計に作用する可能性があります。言語とプロジェクトの進化についてあなたが言うことによると、後者を選択する傾向があります。

于 2012-10-29T13:42:40.350 に答える