.NETソリューションのディレクトリ構造

最近、請負業者を訪問し、プロジェクトの構造化の方法論について質問しました。特にディレクトリ構造について言及していることに注意してください。彼は、Microsoftのガイドラインを使用することを提案しました。「Microsoftガイドライン.NETプロジェクトのディレクトリ構造」をGoogleで検索して、何か役立つものを見つけることができると思いましたが、そうではないことが判明しました。現状では、次のようなことをしています。

[Company.System.Feature]
  |-doc
     |Sandcastle project
  |-lib
     |Nuget packages
  |-src
    |-Project1 e.g. web
    |-Project2 e.g. business logic
    |-UnittestProject1
    |-Specs

docフォルダーには、https：//www.codeproject.com/Articles/15176/Sandcastle-Help-File-Builderで説明されているようなSandcastleソリューションが含まれています（絶対パスと相対パスを参照）。したがって、docフォルダーには、生成されたヘルプファイルを含むヘルプフォルダーが含まれます。libフォルダーには、すべてのNugetパッケージが含まれています。

ソリューションの構成方法を推奨するマイクロソフトのガイドラインはありますか？私はここを見ました：https : //stackoverflow.com/questions/789389/project-structure-for-c-sharp-development-effort/789554? noredirect=1 # comment86756309_789554 私が読んだ記事や質問のほとんどは2007年から2009年に作成されたようです。Nugetは2010年に導入されたと思います。Microsoftのガイドラインはありますか？：私は、しかし、これはもう存在していないようです、ツリー外科医と呼ばれるものについて読んhttps://archive.codeplex.com/?p=treesurgeon。

TFSを使用しています。クルーズコントロールとDDDは、それによって違いをもたらします。

MSDNには、非常に古い公式ガイドラインがいくつかあります。ただし、これらは古くなっています。ページにあるように、「このコンテンツは古くなっており、現在メンテナンスされていません。これらの技術をまだ使用している個人のために提供されています。」これらのガイドラインは避けることをお勧めします。

Project Scaffoldを介して共通のソリューション構造を定義しようとしました。ただし、これはC＃よりもF＃に向いています。それは実際にはうまくいきませんでした、そして最近のアイデアの発展の兆候はほとんどありません。

最もアクティブで最新のガイドラインは、MicrosoftのASP.NETチームの開発者であるDavid Fowlerによって維持されています。これらのガイドラインは、Roslyn（C＃およびVB.Netコンパイラー）チームを含むマイクロソフト内の多くの企業で使用されています。したがって、そのアプローチを採用するよりもはるかに悪い結果をもたらす可能性があります。