The guidelines discuss the service layer with its service interfaces and data/message/fault contracts. They also discuss the business layer with its logic/workflow components and entities as well as the 'optional' application facade.

What is unclear still to me after studying this guide is where the implementations of the service interfaces belong. Does the application facade in the business layer implement these interfaces, or does a separate 'service facade' exist to make calls to the business layer and it's facade/raw components?

(With the former, there would be less seemingly trivial calls to yet another layer, though with the latter I could see how the service layer could remove the concerns of translating business entities to data contracts from the business layer.)


Think about a cake, each layer is put separately and contains all the ingredients that define this layer.

You can make a similar cake recipe with a different 3rd layer or use this layer in another cake recipe. If the layers taste good together (interfaces), the recipe (application) will work.

The goal of each layer is to provide different and specific tastes without mixing them together so that the tastes are easy to understand individually and easy to change.

The Service Layer is a specific component to interface your business with your UI or service clients and add another decoupling step between your final consumers and your business. The implementation of the service interfaces does not contains -a lot of- business logic but is -only- a serving hatch to your Business Layer.

So yes, the implementations of these services interfaces are in the Service Layer and reflect only the contracts : don't do too much here, it is not your business (check the Design Considerations).

The Application Facade is another serving hatch to hide the inner logic of your business elements and provides an easier way to access the business logic. If you have of facade, your services should point to it.

  • So the "business logic" in those service layer classes is more like "serialization logic", right? Thanks for your answer by the way – user44798 Dec 28 '13 at 17:52
  • You can do much than only messages serializations like transformations (of values), validations (of messages values) and so on but yes, you can say that one of the main point of this layer is to put messages between your final consumers and your business to avoid exposing your business elements directly and let the service layer deal with the publics contracts (and "public serialization"). – JoeBilly Dec 29 '13 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy