The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

gehki (1) [Avatar] Offline
The Martin Fowler says...
"A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coor-dinating responses in the implementation of its operations."

Service Layer is commonly used as Facade... What the real advantage of using both Facade interface and Service interface if I can apply the transaction demarcation (and other services) to the Service Layer?
ceracm (113) [Avatar] Offline
Re: Facade versus Service
Thanks for your post.

Often the facade and the service are combined into a single interface+class.
However, sometimes it can make sense to separate them out.
For example, consider the TransferService from chapter 1.
Its pretty focussed on transfering money between two accounts: finds the accounts, calls debit() on one and credit() on the other.

Imagine that after the web tier calls TransferService it wants to display lots of information about the customer: a list of their accounts, last 5 transcations of each et etc.
The TransferService could return all of that data - but this would make it more complex and less focussed on transfering money. Perhaps a violation of the Single Responsibility principle (

The alternative would be to have a facade that calls the TransferService and then does all the extrawork. I think that would be cleaner in many situations.

I've seen a similar need for such a separation in EJB applications. Each service method contained code to fulfill its core responsibility AND lots more code to create DTOS etc.

So in summary: a facade is not always necessary but in some situations it can enable the service to comply with the Single Responsibility Principle.

I hope this helps.

urgo (2) [Avatar] Offline
Re: Facade versus Service
What do you think about putting that extra work inside controller?

If that extra work is something presentation dependent then it should be OK to have such stuff there.
zartc (13) [Avatar] Offline
Re: Facade versus Service
IMHO, by the time your code reach the controller, the persistance session will be closed and it will be too late to load lazy objects in the returned object.
obfscr (1) [Avatar] Offline
Re: Facade versus Service

Isn't TransferFacade will become Service itself? Now user asks Facade to perform logic and get desired info to show on UI. Thus Facade represents use case and represents application boundary now. Why not use Service in that case too? Service will delegate calculations to needed business classes and application logic (not business) in service will coordinate responce. Other possible variant is to define another service (or rename existing in order to represent not operation but business entity, for example Account: AccountService. and add needed method here) which will focus on needed data retrieving.

Also, it is possible to define Facade inside Service, TransferFacade, which will encapsulate needed logic.

What do you think?


simbo1905 (30) [Avatar] Offline
Re: Facade versus Service
@urgo "What do you think about putting that extra work inside controller? "

One of the important things that the facade is doing is scoping the database transaction. In psudo-code the UI controller would be doing something like:

myEntityList = facade.processOrder( .... ); /* db transaction scoped to this one line */

You can of course choose to let the transaction scope run over the whole web request. That is what the Open Session In View pattern does.

If you know that you are going to need many application server JVMs on many servers then you want to keep the database transaction scoped to the smallest amount of code as possible to get the best scalability. If you have an app which is not going to get a very large user load (e.g. no money in the budget to run it across multiple servers) then using Open Session In View is easier. The extra work of going via the facade is the extra effort required to try to get the best insulation of your database from high user load.

Sometimes with a low complexity app the facade looks like overkill between a ui controller and the services. In which case you can in-line your facade code using a spring transaction template. In pseudo-code:

/* this forum software does not let me format the following code nicely */
myEntityList = (List)this.transactionTemplate.execute( new TransactionCallback() {
Object doInTransaction( TransactionStatus ts ) {
service.processOrder( order );
return repository.findOrders( customer );
} ); /* db transaction scoped to that one "execute" method call where i supplied in-line code. */

Now I grant that if one is not really used to using the spring template method pattern (which is what that anonymous inner class is all about) then that second approach looks like a whole world of hurt when compared to the first. Spring has many Template classes however that you use in a similar manner with so it is a well understood pattern which is worth getting used to as it has great power. With great power comes great responsibility not to abuse it smilie That anonymouse inner class pattern is also something that works well with event driven programming patterns such as the Observer Pattern so it is worth getting familiar with.
simbo1905 (30) [Avatar] Offline
Re: Facade versus Service
@ obfscr "Isn't TransferFacade will become Service itself?"

PiA talks about Services (with a capital 'S') and describes them as a part of the Domain Model. Like the Entities. (And also the Repositories which makes them different from old-school DAOs). In contrast it says that the Facades are not part of the Domain Model. They are fulfilling the Use Cases of the system but they are a Client of our Domain Model.

My interpretation is that Services (as in the Domain Model bits) should do one thing and do it well: enact the multiple entity business logic in a re-usable manner (delegating logic to the entities where possible). That way they can be re-used across multiple facade methods which implement slight variations of the system use cases. Likewise the Entities should do one thing and do it well: model the business records within the system and encapsulate any single entity logic. That way they can be re-used across multiple service methods and by many different services.

Going with that description it is clear that a Facade is not a domain model Service. A Facade should do one thing and one thing well: enact the system Use Cases making maximum re-use of the Domain Model (the Services, Entities and Repositories). A given Facade can be used to group together related use cases into one logical place. As a general rule though Facades should not be calling across to one anothers methods in the same way that logic on one screen trying to reuse logic in another can lead to a mess. Instead re-usable logic should be pushed into the correct class of the Domain Model (usually a Service) else shared by moving logic to a Facade base class (but never a procedural Utils class!)

I would still choose to put the Facades into the part of my system diagram that is usually labeled as the "business services layer". This is because they are doing the business logic and are not part of my presentation layer. Of course thats an architectural layering label not a label of the types of classes in the layer. To avoid confusion I should drop the word "services" from my diagram and call it the "business layer" meaning the logic of the system that enacts the use cases independently of the presentation.

@obfscr "Also, it is possible to define Facade inside Service, TransferFacade, which will encapsulate needed logic."

I would not. As per my other post on this thread I might consider in-lining the facade logic into the UI controller of a low complexity application. By low complexity I would mean one where their were a small set of screens that completely related to specific use cases. In such a system the screen controllers would cover the ground which would be covered by the Facades for the use cases. In a high complexity app though the PiA layering and devision of responsibilities makes sense. In a large application the UI controllers should do one thing and one things well: control the screen (not control the app! A big error that people make when writing mvc or desktop controllers). The Facades should control the app (by implimenting the use cases by orchestrating the Domain Model objects).