3

Eric Evans の DDD: Tackling Complexity in the Heart of the Software を読んでいて、コンテキスト マップのセクションで、Evans はトランスレータを使用してそれらを統合する 2 つの境界付けられたコンテキスト (予約コンテキストとネットワーク トラバーサル サービス) の例を引用しました。

私の理解が正しければ、モデルを作成するときに、ドメインの概念的な境界を作成する境界付けられたコンテキストにすべてを入れます。私の質問は次のとおりです。

  1. すべてが限定されたコンテキストにある場合、翻訳者はどこに配置する必要がありますか? Evans のサンプル ダイアグラムでは、翻訳者は両方の境界付けられたコンテキストの外 (中間) にあります。

  2. ERP に取り組んでいるチームが 1 つあるとします。ERP を複数の境界付きコンテキストに配置するか、単一のコンテキストに配置するか。Evans のサンプルに基づいて、複数のチームが独自のモデルで作業できるように、境界付けられたコンテキストが考案されました。しかし、これは単一のチームであるため、統合が問題にならない単一のモデルでメリットが得られるのではないでしょうか? それとも私はこれを間違って理解しましたか？

  3. 質問 2 の場合、境界付けられたコンテキストが複数ある場合、実装で、Payroll で使用する Accounting のクラスが必要な場合はどうなりますか? ここに翻訳者は必要ないと思いますが、必要なクラスを共有する方法がわかりません。別の境界付けられたコンテキストから必要なクラスを参照するだけで問題ありませんか?

  4. 最後に、DDD のモジュールは境界付けられたコンテキストにどのように関連していますか?

4

2 に答える 2

5

  1. インフラストラクチャ層 (ドメイン外) では、これは技術的な詳細です。

  2. 境界付けられたコンテキスト (BC) はドメインから出現します。そのため、それらを識別し、定義しません。特定された後、多くの BC があり、利用可能な開発者がいる場合は、アプリケーションをより迅速に開発できるようにワークロードを分割できます。単一のモデルはお勧めできません。BC ごとに単一のドメイン モデルと、クエリ用の簡略化された読み取りモデル (CQRS) が必要です。

  3. わかりませんが、私にとって給与計算は経理の一部であり、実際には 2 BC はありません。アカウントは BC ですが、他の BC では給与が必要になる場合がありますが、その定義は BC に固有のものです。そしておそらく、定義は実際には単なるデータ (読み取りモデル) です。給与計算の動作は会計にとどまる必要があります。そのため、各 BC が「Payroll」によって理解していることを明確に定義する必要があります。通常、BC の概念と「トランスレータ」の両方を使用するドメイン サービスがあります。

  4. そうではありません。モジュールは、技術的な観点から物事をグループ化するだけです。BC は非常に仮想的なものです。1 つの BC に対応するプロジェクトまたはモジュールを選択することもできますが、それをどのように整理するかはあなた次第です。

于 2014-05-08T16:11:03.137 に答える
0
  1. すべてが限定されたコンテキストにある場合、翻訳者はどこに配置する必要がありますか? Evans のサンプル ダイアグラムでは、翻訳者は両方の境界付けられたコンテキストの外 (中間) にあります。

この質問は無意味だと思います。各 BC はドメイン モデルが存在する境界であり、その境界は UL によって決定され、各 BC には独自の UL があります。モデルを 1 つ作成するだけであれば、翻訳は必要ありません。大きなモデルをいくつかの小さなモデルに分割する代わりに、それらを結合しています。

  1. ERP に取り組んでいるチームが 1 つあるとします。ERP を複数の境界付きコンテキストに配置するか、単一のコンテキストに配置するか。Evans のサンプルに基づいて、複数のチームが独自のモデルで作業できるように、境界付けられたコンテキストが考案されました。しかし、これは単一のチームであるため、統合が問題にならない単一のモデルでメリットが得られるのではないでしょうか? それとも私はこれを間違って理解しましたか？

私はあなたが間違って理解していたと思います。利用可能なチームではなく、UL に従って、1 つのモデルを複数の BC に分割します。作成した BC の数に対して十分なチームがない場合、チームは複数の BC を開発する必要があります。ところで、逆は望ましくありません。つまり、BC は複数のチームによって開発されるべきではありません。

  1. 質問 2 の場合、境界付けられたコンテキストが複数ある場合、実装で、Payroll で使用する Accounting のクラスが必要な場合はどうなりますか? ここに翻訳者は必要ないと思いますが、必要なクラスを共有する方法がわかりません。別の境界付けられたコンテキストから必要なクラスを参照するだけで問題ありませんか?

別の BC のドメイン オブジェクトを参照しないでください。その BC は、アプリケーション層であるドメイン モデルを保護する必要があります。アプリケーション層は、DTO、プレーン オブジェクトを公開します。ドメイン モデルを外部に公開するべきではありません。あなたが求めているのは、共有カーネル (他の BC によって共有されるモデル) です。

  1. 最後に、DDD のモジュールは境界付けられたコンテキストにどのように関連していますか?

モジュールは単なる Java パッケージであり、互いに関連するものをまとめておくのに役立ちます。したがって、BC のソース コードをモジュールに分割します。技術的な側面ではなく、ULに従ってください。たとえば、エンティティのモジュールではなく、各集約のモジュール、リポジトリの別のモジュールなどです。

于 2017-10-22T16:16:42.387 に答える