問題タブ [bounded-contexts]

つまり、物理的に、コードで。ネーミング、名前空間、フォルダー、アセンブリ、データベースの編成。

制限されたコンテキストはどのように相互作用する必要がありますか？

たとえば、従来のeコマースビジネスドメインを自由に使用できます。

私のドメインには、この質問に関連する 2 つの境界付けられたコンテキストがあります。

1. 購入 - 顧客がサービスを注文する場所
2. フルフィルメント - サービスがベンダーに割り当てられて完了する場所

注文の有効期間中、いつでも顧客が注文を編集できることが要件です。

顧客が注文からサービスを削除する場合 (つまり、購入コンテキスト内)、そのサービスが実行するベンダーに既に割り当てられている (まだ実行されていない) 場合、そのサービスはフルフィルメント コンテキストでも削除する必要があります。

ここにはいくつかのオプションがあります。コミュニティの意見をお聞かせください。

1. これによりクロスコンテキストトランザクションが作成されるため、コンテキストが間違っています。
2. ここでは、トランザクションの一貫性は必要ないかもしれません。もちろん、それはビジネス関係者が決定することであり、2 つの質問があります。実装オプションは何ですか? この質問をビジネス関係者にどのように提起すればよいでしょうか?
3. これは、「クロス コンテキスト トランザクションを禁止する」というルールに違反しても問題ありません。

編集

これはすべて 1 つのプロセス内で行われるため、トランザクションの途中で失敗する可能性は非常に低くなります。

私は最近、ドメイン駆動設計の原則を採用していますが、境界コンテキストの実装、およびコンテキストや他のシステム間の統合に少し問題があります。

たとえば、次のシステムを考えてみましょう。

倉庫/在庫管理システムエンティティには、「数量」、「場所」などのプロパティを持つ「製品」が含まれます。

オンライン注文システムエンティティには、「Order」、「OrderLine」、および「Basket」が含まれます。'Price'などのプロパティを持つ独自のProductエンティティもありますか？

注文システムの明確なビジネスルールの1つは、在庫がない製品を注文することはできないということですが、この情報は在庫管理システム内にあります。私が理解していることから、これらはこれを実装するいくつかの可能な方法です：

1. 注文が検証されると、Orderオブジェクトは在庫管理システムのサービスを呼び出して、必要な各製品の在庫が十分にあることを確認します。ただし、ドメインが別のシステムのアプリケーションサービスを呼び出すことについて何かが正しく感じられません。また、すべてのシステムがこれを実行している場合、すべてが密接に絡み合って結合されることになります。

2. Ordering Systemは、Stock Keeping Systemのデータベースから読み取ります。OrderingSystemのProductエンティティは、OrderingSystemのProductテーブルとStockKeeping SystemのProductテーブルの結合にマップされます。または、OrderingSystemProductエンティティには次のものが含まれます。 StockKeepingSystemからの値を持つStockKeepingProductと呼ばれる別のエンティティ。これは検証を実行するのは簡単ですが、注文システムが在庫管理システムのデータベースに決して書き込まないようにする必要があります。

3. 在庫の数量は注文システムのデータベースに非正規化され、在庫保持システムの在庫が変更されるたびに、注文システムにメッセージを送信して在庫を更新します。

おそらく、私は3を実行する必要があることを知っていますが、非常に多くの冗長なデータと考えられる不整合を処理する準備ができているかどうかはわかりません。1と2についてどう思いますか？または他に何か提案はありますか？

それらの間で懸念が共有されている境界付けられたコンテキストを定義する方法と、これをドメインエンティティで表現する方法について混乱しています。

例: 顧客は Customer コンテキストで多くの製品を持っています。会社は Company コンテキストで製品のリストを持っています。

したがって、顧客は顧客コンテキストを介して管理され、会社は会社コンテキストを介して管理されます

コンテキストが異なるモジュールにあるとします。

商品と一緒に会社の住所を教えてほしいのですが、どのようにすればよいですか？

顧客を含むモジュールで Company コンテキストを含むモジュールを参照するか、それとも顧客と対話するときに使用するために顧客コンテキストで Company エンティティを作成するか?

ありがとうございました

複数の境界付けられたコンテキストでエンティティがどのように動作するかを理解しようとしています。

会社の従業員を指定します。(たとえば) 人事のコンテキストでは、この人物は名前、姓、住所、給与参照番号、および銀行口座を持っています。しかし、経理のコンテキストでは、関連するのは給与参照番号と銀行口座だけです。

SalariedEmployeeHR コンテキストに Employee エンティティがあり、経理コンテキストにValue-Type (例: ) がありますか?

SalariedEmployeeクラス (??) : 従業員の値型

境界付けられたコンテキストの HRService はこの情報を返しますか? それとも、両方のコンテキストで Employee クラスを使用しますか?

Java ModelinginColorのPartyPlaceThingとRoleの原型を使用しようとしています。

さらに、DDDのベストプラクティスを取り入れようとしています。ここで、アプリケーションに顧客と患者という2つの役割を演じる1人の担当者がいると仮定します。

CustomerロールはCRMBoundedContextで使用され、PatientロールはHospital ManagementBoundedContextで使用されます。

私のロールクラスは、弱いID、Personを一意に表すことができる値オブジェクトを使用して、Personの詳細にアクセスできます。このアプローチの詳細は、ここにあります。

現在、Party Place Thingの原型では、指定された責任の1つは、パーティーが果たしている役割をリストアップする機能です。

役割が異なる境界コンテキストに存在する場合、これをどのように達成しますか？

したがって、理想的には、顧客と患者は、人と同じ境界のコンテキストに存在するべきではありません

私たちは DDD を学習し、レガシー システムとデータストアに支えられたシステムでの使用を評価しています。

私たちは Anti-Corruption Layer、Bubble Context、Bounded Context を知らずに使用してきましたが、このアプローチは非常に実用的です。

しかし、識別方法と同一性相関については確信が持てません。従来のデータ ストアには主キーがなく、代わりに複合一意インデックスを使用して情報を識別します。

現在、エンティティである必要がある値オブジェクトとしてモデルを作成しています (すべてに「Long id」フィールドを追加したい)、または一意のインデックスで使用される属性の組み合わせを id フィールドとして使用することはめったにありません。エンティティ モデルに id フィールドが必要であることは明らかです。

ここに私の具体的な質問があります：

• 光沢のある新しいエンティティには、理論的には「Long id」フィールドが必要です。バックエンド データ ストアがそのフィールドに値を入力したり認識したりできないため、値が得られないため、そのフィールドを追加しなくても大丈夫ですか?
• DDD の方法で識別情報を保存し、後でそれをリファクタリングしても問題ありませんか?データストアがニーズに合わせて変更されることを願っています。
  • もしそうなら、エンティティからの識別を抽象化することは良いアプローチですか（つまり、識別可能なインターフェース、またはエンティティごとのキークラスですか？-ここで良いアドバイスが必要です..）
• この質問は DDD の範囲外かもしれませんが、識別リファクタリングがシステムのいくつかのレイヤーに影響を与える可能性があるのではないかと思います (たとえば、REST API は/entity/id_field/id_field/id_fieldから/entity /new_long_id に変更される可能性があります) 。

と他の質問:

• 洗練されたドメイン モデルを成長させるためにレガシー情報をどのように使用すればよいでしょうか。

• それとも、プロジェクトの存続期間中いつでも、ドメインのロング IDを希望するのは悪いことであり、価値がないのでしょうか?

• アイデンティティ管理をどのようにリファクタリングできますか?

アップデート：

• ID 管理は DDD の重要な側面ですか、それともリファクタリング可能なインフラストラクチャーの側面なので、これ以上時間を費やすべきではありませんか?

REST インターフェイスを備えた異なるデータベースを使用する 3 つのサービスがあります。

• 初回サービス：お客様情報
• 第二のサービス：顧客取引に関する情報
• 3 番目のサービス: 顧客ドキュメントに関する情報

問題: すべての顧客には、取引と文書に基づいて評価する必要があるステータスがあります。

この評価を担当するのはどのサービスで、他のサービス間のオーケストレーションはどのように実装すればよいですか?

現在のプロジェクトを再構築して、DDDのベストプラクティスに沿ったものにしています。

このセットアップの一部として、管理タスクにより、特定のドメインオブジェクト/アグリゲートを構成ファイル/アルゴリズムの組み合わせに基づいて（再）ブートストラップすることができます。たとえば、テスト（テキストフィクスチャ）だけではなく、ライブシステムの一部である必要があるこのユースケースがあります。

DDDコンテキストでこれを最適にモデル化する方法に苦労しています。

基本的に：ビルダー/ブートストラッパーは、ドメインオブジェクトと同じ境界コンテキストに属するインフラストラクチャサービスでしょうか？これは自然に感じますか？私が見るフローは、管理者が特別な管理アプリケーションサービスを使用してこれらの機能にアクセスし、ビルダーを呼び出して作業を行うことです。

一方、この管理機能はシステムの別の部分のように感じるので、ブートストラップをサポートするメソッドでドメインオブジェクト（またはそのファクトリ）を汚染するべきではないかもしれません。IOW：これは、完全に異なる（ロジックのない）ドメインモデルがDBへの永続化に純粋に使用される、別個の境界コンテキストを意味する可能性があります。ただし、モデルを2回（各BCに1回）定義することになる可能性があるため、それは私にはあまり乾燥しているとは感じません。

これについて行くための最良の方法は何でしょうか？

NServiceBus を使用して、外部サービスに顧客情報を要求し、タイムアウトを発生させるサガを作成しました。タイムアウトの期限が切れた後、そのサガは外部サービスに応答があるかどうかを確認します。それに応じて、対応する顧客のデータがあり、その対応する顧客がシステムに存在するかどうかを確認する必要がある状況があります (存在しない場合は作成する必要があります)。その後、それを参照する追加の監査エンティティを作成する必要があります。顧客 (それらを作成するために必要な情報がすべて揃っている場合)。

特定の顧客が存在するかどうかを確認する方法と、顧客を作成する方法がない場合はどうすればよいのだろうか。

これまでのところ、いくつかのアイデアがあります。

• メッセージ ハンドラー内から WCF サービスを呼び出す (チェック、作成)

• NSB 経由で Customer 境界コンテキストにメッセージを送信し、ID を含む応答を待ちます。