4

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

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

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

オンライン注文システムエンティティには、「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についてどう思いますか？または他に何か提案はありますか？

4

1 に答える 1

1

また、すべてインフラストラクチャに依存します。1つのネットワークで2つのシステムを実行しているため、通信が中断する可能性が最小限である場合、ソリューション1に問題はありません。StockKeepingSystemへの呼び出しをアダプターにラップし、変更する場合に備えて、将来簡単に交換できます。在庫管理システムのAPIまたは完全にそのようなシステム。また、注文システムへの詳細の漏洩を回避します。

ソリューション3はより高度で、実装と保守に多くのリソースを必要としますが、これら2つのシステムを完全に分離することができます。OrderingSystemがStockKeepingSystemが処理できるよりも多くの要求を処理する必要がある場合など、ネットワークの中断やパフォーマンスのボトルネックをより適切に処理します。

ただし、1）と同じ方法で実装できます。アダプタを使用して分離します。DDDの観点から見たIMHOに違いはありません。

于 2011-07-02T03:52:43.803 に答える