マイクロサービス用の単一のプロジェクト内のフォルダーとVisual Studio内の個別のプロジェクト
質問が広すぎるのか、意見に基づいているのか不明です。とにかく尋ねますが。
私は、Microsoftの「Architecture eBook」を通じて通貨を読んでいます https://www.Microsoft.com/net/learn/architecture を見つけました。 Githubにあるサポートソリューションがあります https://github.com/dotnet-architecture/eShopOnContainers
サンプルアプリケーションは、さまざまなテクノロジーとインフラストラクチャのコレクションとともに、マイクロサービス内に実装するさまざまなパターンを提供します。
これは私の質問につながります。
Ordering.APIプロジェクト（ https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src/Services/Ordering ）を見ると、作成者はドメインとインフラストラクチャを配置することを選択しました別のプロジェクト内のコードを、それらを使用しているマイクロサービスAPIに追加します。
この画像は、3つのサービスを示しています。1つは複数のプロジェクトで実装されています。
奇妙なことに、プロジェクトは以前はさらに分割されていました。 Ordering.APIプロジェクトの一部となったOrdering.Applicationプロジェクトもあります。ドキュメント内の古い画像はこれを示しています。
マイクロサービスは、定義された境界コンテキストを持つという点で自己完結している必要があるため、これらのドメインモデルをこのマイクロサービスの外で使用しないでください。順序付け内のフォルダー構造ではなく、このようなプロジェクトを構造化するメリットは何ですか。 APIプロジェクト？
Quicker builds。マイクロサービスに単一のプロジェクトがある場合、すべてを再コンパイルする必要があります（コンパイラの最適化にもかかわらず）。コードを複数のプロジェクトに分割した場合、変更するプロジェクトとそれに依存するプロジェクトのみが再コンパイルされます
証明可能な分離コード。狭く分離された機能を持つマイクロサービスでも、分離コードの基本が適用されます。さまざまな独立したプロジェクトでさまざまな懸念がある場合は、組織化された方法で層を分離したことを確認する方がはるかに簡単です。たとえば、データアクセスにORMを使用しているとします。プロジェクトを使用しないと、コントローラーでORMを使用していないことを簡単に証明できますか。プロジェクトの場合、コントローラーはデータアクセスレイヤーとは異なるバイナリにあるため、証明するのはかなり簡単です。コントローラープロジェクトがそれを参照することすらありません。
より簡単な単体テスト。内容をプロジェクトに分割すると、データアクセスやWebホスティングに使用しているすべてのクレイジーサードパーティフレームワークへの参照を含める必要がなくなります。コアビジネスロジックをテストします。確かに、完全な世界では100％のコードカバレッジが必要ですが、完全な世界ではありません。単純なものをテストすることが難しいほど、テストされる可能性は低くなります。
小規模な展開。 .NETプロジェクトは、多かれ少なかれ、出力側でDLLに変換されます（これは単純化ですが、一般的に、特に回避しない限り、これが最終結果です）。 1つのプロジェクトのみを変更する場合は、1つのDLLを再デプロイするだけで済みます。 （とにかく自動ビルド/デプロイメントを使用する必要があるため、これはプロジェクトとフォルダを選択するのはひどい理由ですが、それでも理由です！）