Вид загруженного вопроса, но если проблема состоит в том, что слишком много классов препятствуют обнаружению, является ли частью решения, возможно, создание некоторых из этих классов internal, а не public?Если пользователи никогда не будут создавать эти экземпляры напрямую, это может быть частью решения вашей проблемы с беспорядком.
Это действительно во многом зависит от природы API, который вы разрабатываете, и в некоторой степенина вкус.Часто есть один основной класс или набор классов, к которым ваши пользователи будут обращаться чаще всего, например, NLog Logger, AutoMapper Mapper, NoRM Mongo или фабрики классов в целом.Они должны быть передними, центральными и обнаруживаемыми, и вы можете убедительно заявить, что лучше иметь это в своем корневом пространстве имен.
Для других классов (те, которые больше о реализации и меньше об API)Очевидно, что вы хотите быть организованным, но вы можете играть с довольно свободной рукой и организовывать так, как вам удобно, при условии, что части API, которые должны найти пользователи, являются наиболее заметными.Foo.Messages кажется вполне разумным способом начать.С другой стороны, если 90% ваших классов являются подклассами Message, но существует важное различие между сообщениями Сервера и сообщений Клиента или сообщениями Purple и сообщениями Plaid, возможно, Foo.Server или Foo.Plaid являются правильными видами пространств имендля вас.