Пространства имен и структуры папок в c# решениях: как должен папки на диске быть организованным?

Я использую плоский подход. Я нахожу, что вложенная иерархия слишком трудно поддерживает. Я группирую свои проекты в несколько решений, с максимальной возможностью многократного использования и перекрестно ссылающийся в памяти, и всегда находил это удовлетворительным. Пример (проекты располагаются с отступом):

CompanyName
  CompanyName.Core
    Class1
    Struct2
    Enum3
  CompanyName.Data
  CompanyName.Web

CompanyName.Projects
  CompanyName.Projects.Core

CompanyName.Projects.ProjectX
  CompanyName.Projects.ProjectX.Core
  CompanyName.Projects.ProjectX.Website
  CompanyName.Projects.ProjectX.ToolY

и т.д. и т.д.

Править: удаленный комментарий ерунды

Я не большой поклонник вложенных проектов, так как это прокладывает проекты под землей глубоко в структуре и если необходимо снова использовать тот проект в другом приложении затем, что Вы делаете, скопировать/вставить код? Мне нравится следовать своего рода за плоской структурой, но организованный пространством имен.

Это - то, как я делаю это:

- DataHelpers\
---Factory\
---DataAccess\
---...
- Components\
--- EmailProcessor\
--- ErrorLogger\
- Desktop\
--- WindowsApp1\
- Services\
--- WindowsService1\
--- WindowsService2\
- WebApps\
--- WebApp1\
--- WebApp2\

Теперь, в каждом основном приложении я имею, например:

- WindowsService1\
--- WindowsService1\ (this contains all *.cs, bin, obj, etc and .csproj file)
--- Solution\ (this contains the .sln file where you link to other projects like ErrorLogger, etc)

Я надеюсь, что это имеет смысл!

"Прежде всего давайте согласимся, что пространство имен должно соответствовать структуре папок и что каждый артефакт языка [так] должен быть в его собственном файле".

Забавный, это - то, как пакеты работают в Java. Я всегда думал, что разрывание связи между пространствами имен и структурой каталогов считали одним из улучшений этим представленный C#. Разве это не верно? (Простите мое незнание, я - человек Java.)

Я думаю, что необходимо определить предел, где плоский подход больше не работает. Например, если у Вас есть типичная 3-уровневая архитектура в небольшом проекте, наличие 3 проектов на внешнем уровне не является никакой проблемой. Однако, если у Вас есть несколько дюжин, затем своего рода группировка помогает функциональности сегмента и делает целое решение более понятным.

Я всегда делал вложенную иерархию. Это делает это крайне очевидным, где добавить новые проекты к существующему решению и сохраняет Ваши пространства имен приятно организованными на диске. Это также делает формирование рисунка пространства имен по сравнению с проектом более очевидным.