Good domain level naming

Question

annotation

Which name is better?

• Domain.PersonService
• DomainServices.PersonService
• DomainServices.PersonDomainService (consider a few longer names, e.g. PersonDomainServiceModelDecorator )

or something else?

Situation

We have a structure in which for each layer there are some base classes. Ex. Repository, domain services, user interface, etc.

Each logical level has a name that is used as its namespace:

• "Data" for the data level containing the repositories; Ex. Fx.Data.DbContextRepository
• "Services" for the service level (not web); Ex. Fx.Services.CrudService
• "Web.UI" for the web interface layer; Ex. Fx.Web.UI.Controllers.CrudController

We also follow the same rule for final projects with some additional layers:

• "Data" Example. Project.Data.PersonRepository
• "Services" Example. Project.Services.PersonService
• "Web.UI" Example. Project.Web.UI.Controllers.PersonController
• "Objects" for objects of the first code; Ex. Entities.Person
• "Models" for object models; Ex. Models.Person.Criteria, Models.Person.PersonDeleteModel

My focus is on the Domain Service layer, but any ideas about other levels are also welcome.

Finally, we conclude that “Services” is not suitable for “Domain Services”, as this may cause ambiguity between the word “Web Service” or “Domain Service”.

Now we change the namespace "Services" to "Domain" or "DomainServices". But we have one more problem. We put the suffix "Service" for each class of the domain service (example PersonService ). The "DomainService" suffix now seems ugly (example DomainServices.PersonDomainServer or DomainServices.DomainPersonService ).

So it may be prettier to use “Domain” as a namespace, while class names indicate that they are services in a domain namespace (example Domain.PersonService ).

Answer 1

I would suggest two simple ideas:

• try to determine the full names (namespace + type name) without redundancy (the same name - domain, face, service, model, Controller, ... - should not appear twice) if possible

• Get inspiration from the .NET platform itself. There are over 40,000 classes ! Open all the assemblies in a tool such as .NET Reflector or ILSpy, and research this 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 

Well, it has the obvious inconvenience that the same name appears several times in the hierarchy. Well, but why do namespaces (and name aliases) exist. I think this is not such a big problem.

Answer 2

Do you see any difference between Domain and DomainServices in your project? If you want to store services and other domain objects in separate namespaces, I believe that you need to move the PersonService namespace to DomainServices .

In most cases, we do not consider the namespace, we are only talking about classes, so I think it's good if you have a DomainServices namespace. At the same time, if you have one domain in the application and you do not have a plan to split it, I think it would be better to call it Domain.PersonService

As for the word “Doman” in class names, I really don't like it because it adds complexity to the name. You should try to create the application in such a way as to make sure that if you open PersonService , you must be 100% sure that this is a domain service. You know that when you open PersonRepository , this is the Data layer, the same for the domain.

Answer 3

I would do this in one of two ways:

1) Why not have a lookup space for Services :

• Services.Web for web services
• Services.Domain for domain services

In another note, I would remove the Web from the Web.UI (assuming you only have a web interface).

2) If web services actually live on the web tier, they can be in the Web.Services namespace, in which case the Web.UI also acceptable. Domain services will live simply in the Services namespace.

Answer 4

My suggestion would be to <Company>.<Component>.<SubComponent>.<Module>.DLL** . Microsoft recommends something similar to this link http://msdn.microsoft.com/en-us/library/vstudio/ms229048(v=vs.100).aspx , and the example will look like this: "Microsoft.Practices. EnterpriseLibrary.Security.Dll

Hence you can go with Company.Domain.PersonService