How to define exactly do not know if I can say, I think open, depends on the project. What you can do is to have some naming conventions. To Microsoft documented this, but nothing prevents people from using other conventions. Note that it is a recommendation that does not always make sense for those who are not developing their own . NET.
A summary:
- Prefix with the name of the organization that owns the project. Just won’t put the whole domain as some guides say to do. Try to be simple. And there’s no case where you can’t use this.
- Use the product name in the second level of the name, without including variations, it has to be something that will always be called that. I think there are cases that this can go to the first level, but it needs to be well thought out and is not an official recommendation.
- Do not create hierarchies within an organization (company) but over stable technologies.
- Use Pascalcase and not the dot to separate words that should be on the same level.
- Prefer the plural whenever it makes sense (I do not see this being so used in practice, there are so many exceptions that complicates following the recommendation, has to go into "common sense").
- Do not use a name of an existing type within it.
- Avoid generic names, try to be more specific about what that is, even if you have to use names composed of more words, qualify the noun.
A part of it is already in Nomenclature standard in code for C#.
Some things not linked to the name but to the organization are more complicated to follow, we do not always have all clear and available vision.
- Avoid placing types of the same name that can be used together and generate conflicts. Leave equal names for technologies that end up being mutually exclusive. Of course there are exceptions, especially when the use occurs in specific contexts.
- Avoid common type names on . NET.
- Avoid names that may conflict with other parts of the same technology. This is one of the reasons I think you should not create many namespaces.
Not that I can’t, but I find it odd to use the same folder structure for the organization of namespace. In general they are different types of organization. Above shows that it is not quite there. You should not have conflicts within the layers of the same solution. It will often have at least partial name duplicity in the type and in the namespace. Of course it has a little taste, if you want to do so always keep this way.