The .NET design guidelines recommends avoiding using the same name for namespaces and a type.

DO NOT use the same name for a namespace and a type in that namespace.

For example, do not use Debug as a namespace name and then also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.

Given the above, it would be recommended to not have a Customer type defined within a Company.Entities.Customer namespace. In which case, there are two possible options I can see:

1. Pluralize the namespace to Company.Entities.Customers and have a singular Customer type within
2. Retain the singular namespace Company.Entities.Customer and leave Customer in the Company.Entities namespace

Both options seem reasonable and the logical grouping of all related types provided with option 1 feels sensible vs having a single type outside of the namespace (likely repeatedly for types with similar naming issues).

Given the two options, is there a standard approach for this situation or is it opinion based (and therefore this question going to be closed)?

CodePudding user response：

Both approaches can be used (personally I would go with second one if selecting from the two), but there are other possibilities worth considering:

1. Add Entities suffix to the namespace name i.e. Company.Entities.CustomerEntities.

2. Switch from the "group by type" approach (i.e. root level folders for entities/repos/controllers/views etc.) to Vertical Slice Architecture (video presentation)/Feature Folders approach which personally I've grown fond of over the last years (see this, this and this).