This is an ASP.NET MVC website.
Following domain driven design, we have a service layer. Our controllers ask application service classes to perform various tasks and then route the results to views.
Business logic is carried out by the service classes.
So for example, I may have an AccountTasks class which is responsible for signing up users, editing their preferences, etc. Now I need to be able to also automatically subscribe the user to a newsletter as soon as they sign up or update their user preferences (then I’d change the newsletter subscription).
The newsletter subscription functionality is thus closely tied to account registration/modification.
However, I feel like it would be better to have a separate NewsletterTasks service class to deal with subscribe/update/unsubscribe actions.
But this class would not be used by the controller, but the AccountTasks class.
So, the workflow would be like this:
-> request made to controller action
-> controller calls AccountTasks
-> AccountTasks creates a user acoount
-> AccountTasks calls NewsletterTasks
-> NewsletterTasks subscribes the user to the newsletter
-> AccountTasks returns the result to the controller
-> controller fetches the appropriate view and sends it to the client
Alternatively, I would have the controller call the AccountTasks first, then using the result call the NewsletterTasks. But with this approach I feel like the controller knows too much about the workflow, whereas it should simply pass around the data and results.
Tasks are Application Service classes, the project is based on S#arp Architecture with some modifications coming from Who Can Help Me – that includes naming conventions for some things.
Is it OK to call NewsletterTasks from AccountTasks? How would you do this?
I’d be tempted to create an explicit UserRegistration Domain Service:
Which in turn answers your question: Yes, it’s OK to call other Services from your Service
Hope that helps!