Service Layer Pattern - Could we avoid the service layer on a specific case?

Question

Hi, 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.

Answer 1

As mentioned in the link you posted, the service layer defines an "interface" for clients by encapsulating the (complex) business logic and centralizing the control of transaction involving several resources. The service layer is not only used when you need to "share" services, it just makes it easier. But even with a single consumer, centralizing the control of transaction makes sense.

Answer 2

"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.