这是一个ASP.NET MVC网站。
遵循域驱动设计，我们有一个服务层。我们的控制器要求应用程序服务类执行各种任务，然后将结果路由到视图。
业务逻辑由服务类执行。
例如，我可能有一个AccountTasks课程，负责注册用户，编辑他们的偏好等。现在我需要能够自动订阅用户的新闻通讯。注册或更新他们的用户首选项（然后我会更改新闻订阅）。
因此，新闻通讯订阅功能与帐户注册/修改密切相关。
但是，我觉得最好有一个单独的NewsletterTasks服务类来处理订阅/更新/取消订阅操作。
但是这个类不会被控制器使用，而是AccountTasks类。
因此，工作流程将是这样的：
-> 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
或者，我会让控制器先调用AccountTasks，然后使用结果调用NewsletterTasks。但是通过这种方法，我觉得控制器对工作流程了解得太多，而它应该简单地传递数据和结果。
任务是应用程序服务类，该项目基于S＃arp架构，其中包含一些来自Who Can Help Me的修改 - 包括某些内容的命名约定。
从NewsletterTasks拨打AccountTasks是否可以？你会怎么做？
答案 0 :(得分：3)
我很想创建一个明确的 UserRegistration 域名服务：
-> 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
反过来又回答了您的问题：是的，可以从您的服务中调用其他服务
希望有所帮助！
答案 1 :(得分：0)
我会提倡控制器调用这两个任务的设计。是的，它给控制器带来了额外的责任，但另一方面，它消除了AccountTasks调用NewsletterTasks的有点尴尬的责任。其他人应该决定是否应该为特定帐户用户订阅简报（事件当前是所有用户都订阅的）。
我会务实地做到这一点：只有2个任务，我将负责在控制器中定义工作流程（可能在一个单独的方法中）。随着任务数量的增加，我将定义一组特殊的类，其唯一目的是定义工作流程。
你的设计看起来有点类似于Juval Lowy的'The Method'，你的任务与他的经理有些相似，所以你可以看看他的paper。