在分层架构中拥有服务依赖关系是一种反模式吗？

Question

在分层架构中让服务依赖于服务是一种糟糕的实践(或者可能是反模式)吗？我注意到，当应用程序是以一种服务可以调用另一个承载业务逻辑的服务的方式设计时，扩展企业应用程序就变得非常复杂和具有挑战性。

想象一下下面的几层：

控制器：

• 控制器A
• 控制器B

服务：

• 服务X
• 服务Y
• 服务Z

仓库

• 储存库K
• 储存库M

例如，Controller A > Service X > Repository K是一个有效的依赖项，但是Controller A > Service X > Service Z> Repository K似乎不是一个很好的实践，因为经过一段时间之后，它可能变得相当复杂。因此，基本上，Controller A > Service X > Service Z> Repository K可以分解为Controller A> Service X> Repository K和Controller A> Service Z> Repository K。我想这一开始可能会增加一些开销，但对于分层体系结构来说，这似乎是一个更好的实践。我想知道是否有任何模式或最佳实践来支持这一点。

Answer 1

这不是一个反模式，但你是正确的，因为它的复杂性。

例如，考虑您的一个存储库可能实际上是一个服务，或者您的一个服务可能使用第三方服务。

您通常希望在抽象层中封装功能，并将抽象层添加到微服务设置中，即抽象为微服务。

然而，一个明确的反模式是有一个循环引用，或者可能跳过抽象层，让子服务对另一个子服务进行相同的调用，而不是共享结果。

如果你把服务保持在一个方向上，并且保持一个方向，那么服务数量本身就不应该成为问题。

Answer 2

服务调用服务确实不是反模式，但由于复杂性的增加，这也不是您想要做的事情。

但有时，需要将不同服务的结果转换为一个控制器，例如，将“学生”和“课程”组合成一个控制器，该控制器显示学生所遵循的课程。在这种情况下，我倾向于在控制器和服务之间创建一个层，名为“编排”。然后，控制器只依赖于业务流程，而业务流程负责组合(或依赖于多个)服务。但是要小心:如果一个业务流程依赖于三个以上的服务，那么设计可能不是正确的。

Answer 3

以订单微型服务为例。

1. 订单微服务不仅有订单控制器->订单服务->订单回购
2. 它将在订单模块中包含控制器、服务、涉及su模块的repos。
3. 通过服务进行子模块之间的交互是不好的吗？不，实际上服务是为这个目的而设计的可重用代码。

简而言之，对服务呼叫的服务一般不是反模式。但是，如果子模块和相应的服务没有得到正确的标识和定义，它就会成为反模式。