マイクロサービス用のVisual Studioソリューションを整理していますか？
主要製品の1つをより マイクロサービス指向アーキテクチャ にリファクタリングし始めています。現在、 Implementing Domain Driven Design フォルダー構造を使用してソースファイルを整理しています。ただし、ドメインプロジェクトとインフラストラクチャプロジェクトは、各マイクロサービスを論理的に整理するという適切な作業を行っていないことがわかりました。
たとえば、「ドメインイベントハンドラ」という概念があります。これは、メッセージを受信したときに機能するものです。現在、これらのハンドラーはすべて、「ドメイン」内の同じ「ハンドラー」フォルダー/名前空間にダンプされています。多分これは大丈夫かもしれませんが、マイクロサービスのコンテキスト間に組織的な分離がないように感じます。別の例はドメインエンティティです。「メンバー」エンティティは、そのマイクロサービスコンテキストに応じて、異なる意味（および異なる構造）を持つ場合があります。
また、今後の展開に問題が発生する可能性もあります。当然のことながら、展開プロセスは可能な限り切り離す必要があります。 10MBの "ドメイン"を使用して各サービスを展開するDLL読み込まれないアセンブリでいっぱいになるのは望ましくありません。
マイクロサービスの論理的な分割を尊重する名前空間とフォルダーでソースを編成するのが最善ですか？各マイクロサービスには、規定された各DDDプロジェクトで独自のソリューションが必要ですか？ 「ツリー内のレベルを上に移動」して、DDD構造の各ノードにsolutionを作成し、各マイクロサービスに個別のプロジェクトを作成する必要がありますか？
ちょっと未知の領域にいるような気がします。ガイダンスをお願いします！
最終的に、devopsパイプラインとマイクロサービスプラットフォームに関する決定が、Visual Studioプロジェクトとソリューションの編成方法を決定する可能性が高いことを発見しました。
最初は、マイクロサービスごとに1つのソリューションが最善の方法であると判断しました。一般的な「コア」ライブラリにも独自のソリューションがありました。 「コア」ライブラリは、内部のnugetフィードを介してホストされ、サービスで使用されます。これにより、必要に応じて、古いバージョンのライブラリでサービスを維持できる柔軟性が得られました。プラットフォームとしてDocker SwarmまたはKubernetesを選択した場合、この「サービスごとのソリューション」の決定はうまく機能したと思います。しかし、最終的にService Fabricを選択することになり、それが決定に影響を与えました。
Service Fabricでは、「アプリケーション」が「サービス」をホストします（このオプションに興味がある場合は、命名法について詳しく読むことをお勧めします）。 Visual Studioソリューションは、これらの依存関係に対応するために多少調整する必要があります。サービスのスケーリング計画によっては、「サービスごとのソリューション」を選択できない場合があります（この回答の範囲外の理由による）。
結論として：まずプラットフォームと開発者を選択してください。サービスあたりのソリューションが理想的だと思いますが、プラットフォームのロジスティクスが法外になる場合があります。
同じソリューションで複数のサービスを維持することは非常に問題がなく、構造をサポートするようにdevopsパイプラインを調整できます。
ビジネスの境界が設計を推進するはずです。論理的に1つのサービスがありましたが、技術的には2つに分割されました-WebサイトとWeb API。それらを同じソリューション内に保持することは理にかなっています。Devopでも個別に展開する必要があります。