Reputation: 873
Should domain services inject other domain services and do work between each other and have the commandhandler be dumb. OR, should the domain services be dumb (only be used to interface the repository barrier) and the majority of work be done in commandhandler's? What is best practices here...
Upvotes: 15
Views: 3828
Reputation: 161
If your 1 service is dependent on other service ,that means you have made some design error . If this the case the just move the code that you want share is some other shared class library so that both services can use it with out any dependency on each other
I would not recommend pouring all the logic in command handler, many parts of the domain could not be set from out of the domain class so I would suggest only write work follow and business logic (not core ) in command handler
Upvotes: 0
Reputation: 53
CommandHandlers could be viewed as the use case's of your application, therefore it is their function to orchestrate the access to repositories, domain services and domain models.
If you start to inject domain services inside each other you start to couple them and lose the single responsibility of each one.
My answer is to let the commandHandler deal with the execution of the domains services and models needed in your use case, this way you can freely compose any new command without having to deal with domain services that are full of logic that belongs to a use case, and not entirely to the domain itself.
Upvotes: 2
Reputation: 4816
I would say add ALL business logic inside domain objects (and also domain services if the functionality doesn't fit into an object) and use commandhandlers for things like:
You can check out the onion architecture, I guess your domainservices are inside Domain Model and commandhandlers inside Application Services.
Upvotes: 12