DDD：電子商取引のサンプルのほかに、バウンド・コンテキストにアプリケーションを分割する方法は？

Question

ここではかなり大きなアプリケーションがあり、DDDのガイダンスに従うために少しリファクタリングすることを検討しています。

現在のところ、ナンバーワンの問題は、バウンド・コンテキストとコンテキスト・マップです。たぶん私はそれを酔っぱらってはいませんが、私は分裂をすることができないようです。たとえば、Userオブジェクトは全面にあり、まったく同じUserオブジェクトです（表示名、ID、ロール）。もう一つの例があります：私たちは、場所のいたるところにある別のエンティティを分類するのに役立つCatalogItemオブジェクトを持っています。 Bounded Contextの依存関係を導入する必要がありますか？その面倒な電子商取引のサンプルの他にこの問題についての指針はありますか？

Answer 1

最初に、境界のあるコンテキストと集約ルートがDDDの最も簡単な概念のように思えました。これは実際に現実の問題を伴うDDDアプリケーションを実際に実装するまでです。簡単な答えはここにありません。ビジネス要件（スケーラビリティ、可用性、待ち時間、一貫性など）に完全に依存します。 「正しい」ソリューションとは、お客様のニーズに最適なこれらの懸念をバランスさせるソリューションです。重複データと

• 一つの大きな有界コンテキスト
• 別々の有界コンテキスト、（おそらくパブリッシュ/サブスクライブ・メッセージング・システムを使用して実装）
• ：あなたが与える例で

  、いくつかの選択肢がありますユーザーとカタログアイテムをそれぞれの限定されたコンテキストにプルし、その他の限定されたコンテキストにサービスを介してアクセスさせます。

クエストニーズを「書く」必要とはしばしば非常に異なっています。これはしばしば、アプリケーション設計を単純化して、純粋にクエリのために境界のあるコンテキストを分離することができます。これが当てはまるように聞こえる場合は、CQRSを調べてください。