服务层模式 - 我们可以避免在特定情况下的服务层吗？ [英] Service Layer Pattern - Could we avoid the service layer on a specific case?

问题描述

我们正在尝试使用服务层模式实现应用程序，因为我们的应用程序也需要连接到其他多个应用程序，并在网络上进行搜索，我们发现了一个示范图形的链接，以正确的方式应用模式：

martinfowler.com - 服务层模式

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

看来，为了实现一个服务层是不必要的;避免服务层更为实际，并且从用户界面到业务层（例如）。在这种情况下应该采用正确的方式来实现服务层模式？你建议我们提出一个类似我告诉你的情景？

提前感谢

解决方案

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

术语层是有误导性的。我认为马丁本人会同意它更好地被称为上下文边界（从域驱动设计）。意味着您可以拥有许多服务层，以不同程度的抽象您的域。您透露给用户界面的服务层API可以在您的域内比您向集成网关公开的服务层做更多的工作。

我会推荐尽可能地分离这些服务功能。 （例如，用于批量导入数据的一组服务和用户正常交互的一组服务应该几乎完全独立。）这样，如果您需要将API暴露给您希望与您进行交互的另一个应用程序以与用户相同的方式，您可以让用户使用与UI相同的API。

we are trying to implement an application using the Service Layer Pattern cause our application needs to connect to other multiple applications too, and googling on the web, we found this link of a demonstrative graphic for the "right" way of apply the pattern:

martinfowler.com - Service Layer Pattern

But now we have a question: what if our system needs to implement some business logic, only for our application (like some maintenance data for the system itself) that we don't need to share with other systems. Based on this graphic:

As it seems, it will be unnecesary to implement a service layer just for that; it will be more practical to avoid the service layer, and just go from User Interface to the Business Layer (for example). What should be the right way in this case to implement the Service Layer Pattern? What do you suggest us for a scenario like the one I told you?

Thanks in advance.

解决方案

"Service Layer" is just an abstraction over your domain logic. The abstraction can be of any degree, including transparent.

The term layer is misleading. I think Martin himself would agree it is better referred to as a context boundary (from domain driven design). Meaning that you can have many service layers that abstract your domain to different degrees. The service "layer" API that you expose to your UI can do a lot more within your domain than the service layer that you expose to the integration gateway.

I would recommend breaking up these chunks of services along functional contours though. (For example a set of services that are uses to bulk import data and a set of services that users interact with normally should be almost entirely separate.) This way if you need to expose an API to another application that you expect to interact with you in the exact same way that a user can you have them use the same API that the UI does.

这篇关于服务层模式 - 我们可以避免在特定情况下的服务层吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！