Good naming for domain services layer [closed]

Question

Abstract

Which name is better?

• Domain.PersonService
• DomainServices.PersonService
• DomainServices.PersonDomainService (consider some longer names like PersonDomainServiceModelDecorator)

or something else?

Situation

We have a framework in which there are some base classes for each layer. Ex. Repository, Domain Services, UI, etc.

Each logical layer has a name which is used as its namespace:

• "Data" for data layer that contains repositories; Ex. Fx.Data.DbContextRepository
• "Services" for domain (not web) service layer; Ex. Fx.Services.CrudService
• "Web.UI" for Web UI layer; Ex. Fx.Web.UI.Controllers.CrudController

We also follow the same rule for end-projects whith some extra layers:

• "Data" Ex. Project.Data.PersonRepository
• "Services" Ex. Project.Services.PersonService
• "Web.UI" Ex. Project.Web.UI.Controllers.PersonController
• "Entities" for code-first entities; Ex. Entities.Person
• "Models" for object models; Ex. Models.Person.Criteria, Models.Person.PersonDeleteModel

My focus is on "Domain Service" layer but any ideas about other layers are also welcomed.

We've finally come to the conclusion that "Services" is not a suitable name for "Domain Services" as it may cause ambiguity between a "Web Service" or "Domain Service" layer.

Now we are changing the "Services" namespace to "Domain" or "DomainServices". But we have another problem. We put a "Service" suffix for every domain service class (Ex. PersonService). Now it seems ugly to have "DomainService" suffix (Ex. DomainServices.PersonDomainServer or DomainServices.DomainPersonService).

So it can be prettier to use "Domain" as namespace while class names show that they're services under domain namespace (Ex. Domain.PersonService).

Answer 1

I would go for two simple ideas:

1. try to define full names (namespace + type name) without redundancy (the same name portion - Domain, Person, Service, Model, Controller, ... - should not appear twice) whenever possible

2. get inspiration from the .NET framework itself. There are more than 40000 classes in there! Open all the assemblies in a tool such as .NET Reflector or ILSpy and study it carefully.

I would come up with something like this:

Domain
 + Person
 + PersonService // Domain service
Domain.Data
 + PersonRepository
Domain.ServiceModel // WCF, etc. I chose the same namespace as .NET Framework
 + PersonService // Service implementation, this is really a service so "service" redundancy seems unavoidable here
Domain.Web.UI
 + PersonController

Ok, it has the obvious inconvenient that the same type name appears multiple times in the hierarchy. Well, but that's why namespaces (and namespace aliases) exists also. I think it's not such a big deal.

Answer 2

Do you see any difference between Domain and DomainServices in your project? If you want to keep services and other domain entities in separate namespaces I believe you will need to move PersonService to DomainServices namespace.

Most of the time we do not look into namespace, we only mention classes that's why I think it is fine to have DomainServices namespace. At the same point of time if you have single domain across the application and do not have plan to separate it, I think it will be better to call it Domain.PersonService

Regarding the word 'Doman' in the class names, I really don't like this because it adds complexity to the name. You should try to build your application that way to be sure if you are opening PersonService you should be 100% sure it is domain service. You know that when you are opening PersonRepository, it is Data layer, the same for domain.