【问题标题】:Is it OK to call one application service from within another application service?从另一个应用程序服务中调用一个应用程序服务是否可以?
【发布时间】:2011-05-06 17:00:24
【问题描述】:

这是一个 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 的一些修改 - 其中包括某些事物的命名约定。

可以从AccountTasks 调用NewsletterTasks 吗?你会怎么做?

【问题讨论】:

    标签: domain-driven-design service


    【解决方案1】:

    我很想创建一个明确的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
    

    这反过来又回答了您的问题:是的,可以从您的服务调用其他服务

    希望有帮助!

    【讨论】:

    • 如果我不引入域服务,但是,如果 AccountTasks 调用 NewsletterTasks(并且有依赖关系,我们使用 DI),您认为仍然可以吗?下面的 Szymon 说他只是把它放在控制器中,但我尽量让我的控制器保持沉默,并将任何业务逻辑委托给服务类。虽然我不愿意再添加一层,但整个架构对我来说已经是一个巨大的飞跃。 :)
    • 我倾向于同意 - 保持控制器“哑”更符合 DDD。我引入 UserRegistrationService 的原因是为了使域操作explicit。但是,如果您的团队说调用 AccountTasks->NewsLetterTasks 感觉更自然,那就去吧。 DDD 是为了让事情更容易理解,更容易改变。
    • 如果以后 NewsletterTasks 需要从 AccountTasks 调用某些东西怎么办?这不会造成循环依赖吗?
    【解决方案2】:

    我会提倡控制器调用这两个任务的设计。是的,它给控制器增加了额外的责任,但另一方面,它消除了 AccountTasks 调用 NewsletterTasks 的有点尴尬的责任。其他人应该决定是否应该为特定帐户的用户订阅时事通讯(事件是当前所有用户都订阅了)。

    我会务实地这样做:只需 2 个任务,我就会将定义工作流的责任放在控制器中(可能在单独的方法中)。随着任务数量的增加,我会定义一组特殊的类,其唯一目的是定义工作流。

    你的设计看起来有点像 Juval Lowy 的“The Method”,你的 Tasks 有点像他的 Managers,所以你可以看看他的 paper

    【讨论】:

      猜你喜欢
      • 2019-02-04
      • 1970-01-01
      • 2015-05-23
      • 1970-01-01
      • 1970-01-01
      • 2015-10-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多