服务层模式 - 我们可以在特定情况下避免服务层吗？答案

【问题标题】：Service Layer Pattern - Could we avoid the service layer on a specific case?服务层模式 - 我们可以在特定情况下避免服务层吗？
【发布时间】：2011-02-05 22:05:23
【问题描述】：

我们正在尝试使用服务层模式来实现一个应用程序，因为我们的应用程序也需要连接到其他多个应用程序，并且在网上搜索，我们找到了一个演示图形的链接，用于“正确”的应用方式模式：

martinfowler.com - Service Layer Pattern

但是现在我们有一个问题：如果我们的系统需要实现一些业务逻辑，只为我们的应用程序（如系统本身的一些维护数据），我们不需要与其他系统共享。根据这张图：

看起来，没有必要为此实现一个服务层；避免服务层会更实际，而只是从用户界面转到业务层（例如）。在这种情况下，实现服务层模式的正确方法应该是什么？对于我告诉你的那种场景，你有什么建议？

提前致谢。

【问题讨论】：

stackoverflow.com/questions/2603750/…的可能重复
我已经删除了重复项。

标签： design-patterns

【解决方案1】：

“服务层”只是对您的域逻辑的抽象。抽象可以是任何程度的，包括透明的。

术语层具有误导性。我认为 Martin 本人会同意将其称为上下文边界（来自领域驱动设计）更好。这意味着您可以拥有许多服务层，将您的域抽象到不同程度。您向 UI 公开的服务“层”API 在您的域中可以比您向集成网关公开的服务层执行更多操作。

不过，我建议您按照功能轮廓分解这些服务块。（例如，用于批量导入数据的一组服务和用户通常与之交互的一组服务应该几乎完全分开。）如果您需要将 API 公开给您希望与您交互的另一个应用程序，那么这种方式就像用户可以让他们使用与 UI 相同的 API 一样。

【讨论】：

没错。大多数人将服务混淆为只是一个事务性边界层，但并非总是如此。

【解决方案2】：

如您发布的链接中所述，服务层通过封装（复杂）业务逻辑并集中控制涉及多个资源的事务，为客户端定义了一个“接口”。服务层不仅在您需要“共享”服务时使用，它只是让事情变得更容易。但即使只有一个消费者，集中控制交易也是有意义的。

【讨论】：