ここにはかなり大きなアプリケーションがあり、DDD のガイダンスに従うために少しリファクタリングすることを検討しています。
今のところ、それに関する最大の問題は、境界付けられたコンテキストとコンテキスト マップです。多分私はそれを理解していないだけかもしれませんが、除算を行うことは不可能に思えます。たとえば、どこにでも User オブジェクトがあり、それはまったく同じ User オブジェクトです: 表示名、ID、役割。別の例があります。さまざまな場所の別のエンティティを分類するのに役立つ CatalogItem オブジェクトがあります。Bounded Context の依存関係を導入する必要がありますか? この厄介な電子商取引のサンプル以外に、この問題に関するガイダンスはありますか?
最初は、境界付けられたコンテキストと集約ルートが DDD の最も簡単な概念のように思えました。これは、現実の問題を抱えた DDD アプリケーションを実際に実装するまでの話です。ここには簡単な答えはありません。ビジネス要件 (スケーラビリティ、可用性、待ち時間、一貫性など) に完全に依存します。「正しい」ソリューションは、これらの懸念事項のバランスを取り、ニーズに最適なソリューションです。
あなたが与える例では、いくつかの選択肢があります：
心に留めておくべきことの 1 つは、クエリのニーズは、「書き込み」のニーズとは大きく異なることが多いということです。多くの場合、アプリケーションの設計を簡素化して、純粋にクエリ専用の境界付けられたコンテキストを分離することができます。これが当てはまると思われる場合は、CQRS を調べてください。