How to define exactly do not know if you can say, I think half open, depends on the project. What you can do is have some naming conventions. Microsoft documented this , but nothing prevents people from using other conventions. Note that this is a recommendation that does not always make sense to anyone who is not developing .NET itself.
A summary:
- Prefix with the name of the organization that owns the project. Just will not put the whole domain as some guides say to do. Try to be simple. And there's no way you can not use it.
- Use the product name in the second level of the name, not including variations, it has to be something that will always be called this way. I think there are cases that this can go to the first level, but it needs to be well thought out and not an official recommendation.
- Do not create hierarchies within an organization (company), but over stable technologies.
- Use PascalCase and not the point to separate words that should be on the same level.
- Prefer the plural whenever it makes sense (I do not see this being so commonly used in practice, it has so many exceptions that it complicates following the recommendation, it has to go "common sense").
- Do not use a name of an existing type within it.
- Avoid many generic names, try to be more specific about what it is, even if you have to use names composed of more words, qualify the noun.
A part of this is already in Naming pattern in code for C # .
Some things not related to the name but to the organization are more complicated to follow, nor do we always have every clear and available vision.
- Avoid putting the same name types 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 usage occurs in specific contexts.
- Avoid common type names in .NET.
- Avoid names that may conflict with other parts of the same technology. This is one of the reasons I do not think you should create many namespaces .
Not that I can not, but I find it strange to use the same folder structure for the namespace organization. In general, there 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. Often it will have at least a partial name duplication in type and namespace . Of course you have a little taste, if you want to do so keep it that way forever.
