How to name the domain services in DDD

Question

I'm new in DDD and I am getting an issue while writing a new project using DDD principles and it's about creating domain services. I always named my services with the corresponding domain object name prefix, such as UserService or OrderService and put all business logic methods related to the DO into these services. So I have UserService, for example, with methods to create a new user, disable an existing user, do some other use case, etc.
Now I notice that I can create one Service for every use case instead of a big service for each DO. For example, a service named CreateUserService and another named RemoveUserService and so on.

The question is, is this new approach recommended or is the previous approach better?

Answer 1

Try to iterate towards DDD and then the 1st step is: object oriented programming. So why would you need an user service? You can have a User.Create(IUserCreator creator) static method on the User object itself to do the trick. Try to encapsulate behaviour into the object where it belongs.

As long as you need just some small data or when everything is avail. via the entity model (or ORM model tree), you won't need a service. Also in lot of cases domain events can help you a lot, these can be implemented multiple ways, one that follows continuous flow (the one I like) or double dispatch - see Jimmy Bogard articles: https://lostechies.com/jimmybogard/2010/03/30/strengthening-your-domain-the-double-dispatch-pattern/ - it's up to personal taste and architecture...

Now if to cretate a UserService or UserCreationService, UserDeletionService - it really depends. Also distinguish between domain services (which should work with pure domain objects, some "interfaces" for complex stuff - or for loading) and between application services (which does more orchestration) - sample: MVC controllers that do: routing, authentication and authorization, data loading, saving, ... Anyhow creating smaller services and using DI can help if you need to swap out implementation + it's the S from solid (single responsibility principle - SRP)...actually in my User.Create(IUserCreation) the IUserCreation is actually an interface of yours UserCreaitonService...

Rearding DDD I can advice you to check out articles from Vladimir Khorikov: https://enterprisecraftsmanship.com/posts/domain-vs-application-services/ He has really good articles out there

Now with ORM the DDD changed a lot and those details are not noted (no books on it). The closest thing you can get about it can be found in my articles, on LinkedIn you will probably need an LI account to access them), anyhow links are here (if you like them, please share):

1. A series of 4 articles on DDD: https://www.linkedin.com/pulse/code-better-ddd-building-blocks-architecture-uow-due-hideghety/
2. Important differences in the repository when ORM is used: https://www.linkedin.com/pulse/orm-repository-pattern-never-good-friends-see-balazs-hideghety/
3. The way to do unit test with DDD (and why not to create or mock dalse repositories): https://www.linkedin.com/pulse/testing-domain-logic-easy-way-balazs-hideghety/
4. And a collection of gotchas when using ORM: https://www.linkedin.com/pulse/get-know-your-orm-avoid-bad-habits-balazs-hideghety/

Also when doing MVC, Jimmy Bogard had a super approach (not just Feature based folder structure) but slices and not layers, so make sure you check this out (haven't used it myself, but it's a good architectural pattern): https://www.youtube.com/watch?v=wTd-VcJCs_M