【问题标题】:Interaction of services in the service layer服务层中服务的交互
【发布时间】:2013-04-07 07:24:48
【问题描述】:

在服务层中组织服务之间交互的最佳方式是什么? 例如,我有文件服务和产品服务。在我的情况下,产品可以有自己的文档,并且为了管理产品的文档,我从产品服务中的文档服务中调用适当的方法。所以,我需要在产品服务中创建文档服务的实例。而且我还需要在文档服务中调用产品服务中的一些方法。因此,这些服务中的每一个都引用了其他服务,我分别得到了 stackoverflowexception。 我应该使用哪些设计解决方案来消除这些问题?

【问题讨论】:

  • 你所拥有的对我来说听起来不是很 DDD。关于设计解决方案不是您作为开发人员的工作吗?

标签: oop architecture domain-driven-design service-layer


【解决方案1】:

显然,循环依赖是错误的

您可以使用shared identifiersProducts 和Documents 解耦。

此外,您可以在应用程序中从外部编排服务交互:在 ProductService 中,您可以让 LoadProducts(ProductIdentifiers[] identifiers) 返回一个不可变的产品集合,在 DocumentService 中,您可以让 LoadDocuments(DocumentIdentifiers[] identifiers) 返回一个不可变的产品集合文件。

【讨论】:

    【解决方案2】:

    应用服务应该为外部客户提供一个 API 来执行有凝聚力的业务操作。应用程序服务方法通常与您的应用程序的用例相匹配。

    虽然应用程序服务操作可能需要调用另一个服务(例如,Create Product 用例包括 Create Document 用例,也可以单独调用),但这不是常态,您应该考虑使您的应用程序服务尽可能内聚。特别是,仅仅因为在您的业务案例中的某个时刻您开始操纵另一种实体并不意味着您应该将该部分委托给另一个应用程序服务 - 换句话说,每个实体一个应用程序服务不一定对。

    无论如何,从您的域中,它应该清楚地显示 2 个应用程序服务之间的依赖关系指向哪个方向。在您的示例中,产品服务似乎依赖于文档服务 - 很难想象为什么会反过来。

    如果您确实需要服务 A 和服务 B 之间的往返行程(除非我别无选择,否则我不会这样做),您可以尝试让 A 的实例将自身注入 B 而不是依赖DI 容器用新实例解决依赖关系,解决堆栈溢出问题 - 如果这就是你首先得到堆栈溢出的原因。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-03-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-05-10
      • 2019-08-02
      • 1970-01-01
      相关资源
      最近更新 更多