過去に、私のプロジェクトは管理が難しくなりました。特に、数年後にやり直したり、すべてをやり直すことなく 1 つの部分を大幅に更新したりするために再訪する必要がある場合はなおさらです。今回は、「プラグ可能な」アプリケーション設計を簡単に作成できるようにすることに重点を置いており、すべてに触れることなく、1 つの部分を再訪してやり直すことができます。
私はこの構造を考えています：
したがって、私が望んでいるのは、境界コンテキスト 2 に取り組み、境界コンテキスト 1 をそのままにして、今後数か月または数年の間に多くの新しい機能でそれを拡張できるようにすることです。また、UI、特に Bounded Context 2 に関する部分にも取り組みます。また、ユーザーが他のデバイスから Bounded Context 2 を操作できるようにしたいと考えています。
境界コンテキスト 2 の UI で使用されている Web テクノロジも更新されることが望ましいです。なぜなら、これが私たちの主な焦点領域であり、最も使用されているからです。ユーザーの管理やユーザーのログインなどの一般的な機能を提供する「ランディング」サイト。
現在、管理を容易にするために、これらすべてを Visual Studio の個別のソリューションに分離することを考えています。しかし、1 つのソリューションでそれぞれのフォルダーを作成し、そこにすべてを配置することができました。
私の質問は、これを行うための推奨される方法は何ですか?また、さまざまなソリューションに分ける前に何を考慮する必要がありますか?
これを管理するためのベストプラクティスはありますか? 何が機能し、何が機能しないかを経験した人はいますか?
ところで、これは境界付けられたコンテキストによって分割されているため、直接的な依存関係はありませんが、システムの部分間の通信が必要になります (つまり、コンテキスト 1 は、コンテキスト 2 で再び必要とされる従業員を登録するためのビジネス ロジックを管理および維持します)。
更新 もう少し情報が必要であることを認識しています。
これら 2 つよりも多くの境界付けられたコンテキストがあります。それらのどれも実際には部門のようなものではありません。つまり、従業員管理は、他の管理に関連する情報を整理/アーカイブし、重要なイベントに関するリマインダーを取得する必要があるときにマネージャーがいるコンテキストです。購買は、従業員が部門のために商品を購入し、棚卸を行うときのコンテキストです。これを使用する組織部門は 20 ～ 40 あります。「レポート」が別の境界付けられたコンテキストであるかどうかを検討しています（ただし、非常に興味深いロジックと動作はありません）。これらは、基本的な機能を提供する小規模なものから始まり、より多くの機能が追加され、人々が新しいニーズを「発見」するにつれて、時間とともに成長する傾向があります。それらは個別に更新されます。かなり基本的なニーズを解決し始めたとしても、そのうちのいくつかがやがてより大きなシステムに成長することを願っています.