15

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...

user3689167
  • 863
  • 1
  • 14
  • 28
  • Start with: https://msdn.microsoft.com/en-us/magazine/mt147237.aspx and https://msdn.microsoft.com/en-us/magazine/mt238399.aspx – Thiago Custodio Dec 10 '15 at 16:11

3 Answers3

12

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:

  • instantiate domain objects and run methods on them,
  • run methods on domain services,
  • provide dependencies to domain objects,
  • manage database transactions,
  • ...

You can check out the onion architecture, I guess your domainservices are inside Domain Model and commandhandlers inside Application Services.

sventevit
  • 4,766
  • 10
  • 57
  • 89
  • Within your opinion at this point, Should I only call domain objects trough domain services? It look inconsistent to have some call domain services and some call domain objects directly.. – kitta Jul 05 '18 at 04:39
  • And also in CQRS, Why shouldn't I have Validator inside command handler instead of domain services? Domain services are nothing much to do because we have already have event sourcing, sagas. – kitta Jul 05 '18 at 04:55
2

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.

gutors
  • 43
  • 7
0

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

Danish Shaikh
  • 161
  • 1
  • 5