Use of the Facade Pattern in software is about apparent elegance on the ‘user’ side of the facade and the hiding of inelegance on the ‘implementation’ side. The implementation can change or be replaced easily over time, but that applies to many patterns. Thus it is the elegance of the facade that’s making it attractive to use in a layered design. There is a second aspect, thought, that is more subtle and often forgotten: reducing the number of calls needed through it. Hopefully to one.

Dishonored Facade Implementations

Just pretend for a second that a object that straddles a divide has gettable and settable things that are representative of more meaningful business things:

public interface Broken {
  void setGivenName(String gn)
  void setFamilyName(String fn)
  String getGivenName()
  String getFamilyName()
}

What we have in the above is something where two are likely to be called in series for typical interactions. We could see that getGivenName and getFamilyName could often be called together when populating an UI’s fields. Similarly setGivenName and setFamilyName could be called together when pushing the UI’s fields back towards persistence:

// populate UI:

gn = b.getGivenName()
fn = b.getFamilyName()

// (elsewhere) persist UI fields:

b.setGivenName(gn)
b.setFamilyName(fn)

If the facade happens to by hiding inelegance of lower level implementation of things that go over a wire, we will now observe two calls over the a RPC or RESTful divide. There are performance consequences that add up quickly.

Honoring Facade Patterns

When the facade pattern is implemented correctly, more data are channelled though fewer invocations (again these are representative of more meaningful business operations):

public class Name {
  // imagine constructor, getter, setter that
  // are characteristic of Immutable or ValueObject
  String firstName;
  String givenName;
}
public interface BetterFacade {
  void changeName(Name name)
  Name getName()
}

What we have now a single operation through the facade that takes or gives something that could be serialized quite easily. Again it does not matter at this stage whether the underlying implementation is a Remote Procedure Call, or something RESTful.

At this level of object granularity, it should be easy to get right.

The Dark Ages of Enterprise Computing

Sun’s late-90’s J2EE is the largest effort to bring bad practice to enterprise computing. Particularly the EJB stuff in its early incarnations. Sun promoted Session Facade as one of the constructs you should code in to your stack. In so doing, they forced a ton of inelegance on the developer. The page I link to shows the J2EE definition from the 2001-2002 era (Oracle could nix it at any time). It is also in the EJB 2.0 style before EJB 3.0 injected some small amount of sanity in 2005. From 1998 to 2004, Sun told folks to make directed graphs of components while constructing applications, that required a ton of boiler-plate code. In the effort to just get it working many teams forgot the desire to reduce invocations across the divide. Java teams are still perhaps forgetful in the years since the progressive abandonment of EJB in particular and J2EE generally since (the mid noughties).

Clues that you are doing it wrong.

While the above diagram does not show categorically an incorrect architecture, even if the there’s a TCP/IP separation between each of the boxes. It does show the start of a fan-out of connections. What starts with one I/O from the browser to the web-tier, results in three I/Os to lower level services. That could be nine more if each of those three did the same to layers below. We might have a constraint in that these have to be separate boxes, and we have to do I/O in series to them as part of the buyCartContents operation. Incidentally, the Catalog node in the above diagram, could have some caching attached to reduce some of our worries, but that is a different thing.

What I am trying to get across at this level of architecture, is the fact that you could quickly engineer something with a lot of downstream invocations that add up while you are otherwise busy with developing functionality. As you’re making your stack, look at the numbers of invocations across divides that could otherwise be facade-like, and worry of the growth of them is uncontrolled. Look at facade methods that are similar to each other, or always invoked in series and could be rolled into one.

One technique for doing it right from the start.

Simply put, you should rigidly stick to top-down design as you build your application stack over time. This is true for the run up to your initial go live, and the in the incremental releases that follow that first push. Do not let Database Administrators (DBAs) drive the design of your web-app. Nor engineers of lower level services. Both of these are ‘bottom-up’ techniques and classic false economies for enterprise development teams. Instead think about the facade like operations from the UI, and change downstream code as appropriate to support that. If that means that your UI teams are more instructional to service teams, so be it.

While adhering to the above, keep busy with your refactoring agenda , even if you are using a language that does not have an IDE as good as Intellij (Java) is. With a decent Agile perspective the right design will emerge at all times.