Martin Fowler’s book “Patterns of Enterprise Architecture” states:

The easier question to answer is probably when not to use it. You probably don’t need a Service Layer if your application’s business logic will only have one kind of client – say, a user interface – and it’s use case responses don’t involve multiple transactional resources. […]

But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning.

The benefits a Service Layer provides is that it defines a common set of application operations available to different clients and coordinates the response in each operation. Where you have an application that has more than one kind of client that consumes its business logic and has complex use cases involving multiple transactional resources – it makes sense to include a Service Layer with managed transactions.

With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations. The responses to creation, update or deletion of a domain object should be coordinated and transacted atomically by Service Layer operations.

Another benefit of having a Service Layer is that it can be designed for local or remote invocation, or both – and gives you the flexibility to do so. The pattern lays the foundation for encapsulated implementation of an application’s business logic and invocation of that logic by various clients in a consistent manner. This means you also reduce/remove duplication of code, as your clients share the same common services. You can potentially reduce maintenance costs too – as when your business logic changes, you (generally) only need to change the service, and not each of the clients.

In summary, it’s good to use a Service Layer – more-so I think in your example you have provided as it sounds like you have multiple clients of business logic.

Adding a service layer because you have evaluated the idea and concluded its the best approach: good

Adding a service layer because that’s what all the cool kids are doing: bad

If your gut says you don’t need one, then don’t make one.

One of the more disappointing developments in the programming world over the past 10 years or so is that it has become annoyingly ‘fashion’ oriented, with people following trends and bandwagons as if they were this season’s shoes. Don’t fall into that trap. Because next season ‘everybody’ will be telling you that you should have designed it some other way.

There’s nothing wrong or right with a service layer – it’s a particular approach whose suitability should be evaluated on its technical merits for the project at hand. Do not feel compelled to substitute other people’s opinions for your own judgement.

There are many factors that go into the decision of creating a service layer. I have created service layers in the past for the following reasons.

1. Code that needs to be re-used by multiple clients.
2. Third party libraries that we have limited licenses for.
3. Third parties that need an integration point into our system.
4. Centralizing duplicated business logic.

Case 1: You are creating base functionality that needs to be used by a myriad of different clients. Service layer builds in functionality for different clients to tap into your provided functionality right out of the box.

Case 2: You normally host code in app space but you are using a third party library that you have limited licenses for. In this case you have a resource you would like to use everywhere, but only a limited number of them. If you host it behind a service then your whole organization can get usage of it from their applications without having to buy a license for each individual hosting.

Case 3: You are building functionality for third parties to communicate to you. In your example you could set up an inventory endpoint to allow vendors to pass messages to you about incoming product shipments.

Case 4: You have analyzed your code enterprise wide and found that separate teams have created the same thing (just implemented slightly differently). With a service layer you can pick the best approach(es) and now you can implement the process the same across all teams by having them call into the service. Another benefit to centralizing logic is when bugs are found. Now you can deploy the fix once and all clients enjoy the benefit at the same time.

All this being said there are potential negatives to a service layer.

1. Adds system complexity. Where before you only had one application to debug now you have two. Production problems require checking client app setting, service app settings, or communication problems between otherwise correctly setup client and server apps. This can be tricky if you’ve never done it before.
2. One point of failure. If you have a service outage all clients are affected. When code is not deployed in this manner the risk can be less (though there are ways to mitigate this).
3. Versioning can be harder to do. When you have one app using a service deploying interface changes can be done at the same time between the two. When you have multiple clients now you must manage who is on V1, who is on V2, and coordinating the removal of V1 (once you know everyone has updated to V2).

The main point is that it’s not always a slam dunk to make your system service oriented. In my experience it usually is a good idea (I tend to structure applications in this way), but it’s not an automatic decision. At the end of the day you need to weigh the pros and cons and make the decision that’s right for your situation.

Most Service Layers I’ve seen are a complete mess. Services tend to have a lot of different methods, 1500 LOC are not rare. The different methods have nothing in common, but do share code. This results in high coupling, low cohesion. It also violates OCP, because every time a new operation is needed, you have to modify the code instead of extending the code base. A well constructed service layer is theoretically possible, but I never seen it in practice.

CQRS solves these problems and prevents you from having to create one of those procedural service layers.

Adding an interface (a service layer is a type of interface) takes time. A good one takes a lot of time to design and test. It is very important to get it right on the first try because changing it later breaks all the clients. Also, consider that you probably won’t know what needs to be in that interface until you have a second client with slightly different needs. Maintaining a service is a never-ending project in itself.

In most organizations, if you go to your business sponsor and ask them, “Do you want other departments to get the benefit of (reuse) this system we are developing with your budget?” they will laugh at you. Get it working for your business sponsor first, then start twiddling around with reusing that code (on your department’s own time).

If you know, for a fact, that the functionality you are writing today will be reused by multiple different service clients, then consider designing a service layer from day one. If you are unsure, or there are many unknowns in the project already, get something simple working first and separate it into service and client later if you have time and budget. It much easier to get the service interface right on the first try when you start with a working system.

P.S. If you are working in Java, Joshua Bloch has a lot of fantastic interface advice throughout his book, Effective Java.

I agree with you. There is no need to include one more layer if you are using a single UI.

DAL,BL and UI/Controller are good combination to design an application. If you are planning to go with a single UI, there is no need to prepare an extra layer. Including 1 more layer into application only increases development efforts/time.

Another schenerio is to use multiple UIs in your application, it is good to have a service layer to handle UIs in this case.

Stack Overflow : Discussion on service layer pattern

I would contest that your BL is your service layer. A central place where your business logic sits. This should be a DLL that can be used by anything that needs that logic. Then you can put a web api layer on top of that if your app will have different UI’s.