Is it OK to call one application service from within another application service?

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:

-> request made to controller action

-> controller calls UserRegistrationService

-> UserRegistrationService calls AccountTasks

-> AccountTasks creates a user acoount

-> UserRegistrationService calls NewsletterTasks

-> NewsletterTasks subscribes the user to the newsletter

-> UserRegistrationService returns the result to the controller

-> controller fetches the appropriate view and sends it to the client

Which in turn answers your question: Yes, it's OK to call other Services from your Service

Hope that helps!

I would advocate the design where the controller calls both tasks. Yes, it puts additional responsibility on the controller, but on the other hand, it removes the somewhat awkward responsibility of AccountTasks to call NewsletterTasks. Someone else should decide whether for a particular account user should be subscribed for a newsletter (event is currently all the users are subscribed).

I would do this pragmatically: with just 2 tasks I would put the responsibility of defining workflow in the controller (maybe in a separate method). It the number of tasks grows, I would define a special set of classes which the only purpose is to define workflows.

Your design looks a little bit similar to Juval Lowy's 'The Method' and your Tasks are somewhat similar to his Managers, so you might take a look at his paper.