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.
- Code that needs to be re-used by multiple clients.
- Third party libraries that we have limited licenses for.
- Third parties that need an integration point into our system.
- 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.
- 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.
- 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).
- 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).
