I have been associated with 3 major softwares that were developed for corporates and large businesses. In each of them, I had seen somewhat common layered architecture where either a facade layer exists for the flow or did not.One of the three architectures had a dedicated facade layer on top of the service/business flows. Incidently it was the only application that was designed for the web.

That could be the reason where the architect might have envisioned mashups of business objects that might be requested from the client side.This decision seemed to be motivated by the controlled requests coming from the web vs the uncontrolled calls on a desktop application.But then, the speed with which the desktop applications have also started gaining back popularity since the past couple of years, it might not be incorrect to assume that the architecture of a web and a desktop application should overlap.The desktop applications are becoming more and more responsive and with an expert user the desktop application demand more challenging screens as compared to web applications.

It is with these understandings I propose the following layered architecture:
The core difference lies in the way the business service calls are divided into two sub layers namely:
1/Facade layer.:: Responsible for mashed-up/secondary business object screens.
2/Business Service layer.:: Responsible for manipulation of core business objects screens.

The process layer calls can go directly to the service layer and also can talk to the facade layer also.

For example, consider the problem domain of bicycles, where we are writing an application for selling of bicycles.

For the initial iteration, the service layer would be enough to cater to the needs of operations like getting a quote of bicycle from different sources, getting different color models, different frame sizes etc.

Later on the application owner might want to move to custom built bicycles where the complete bicycle is not the single object that is passed across the process and service layers, as wheels, frames,handle-bars,seat-posts all start bringing in different compositions for the custom build bicycle.
In this scenario, the facade would be a great place to assemble different parts of the bicycle bind them together and return to the process as the complete bicycle object.
Even later on when the bicycle sub parts are further broken down like the wheel composition can give multiple options to choose from, this structure can be extended further.

Some might argue that the facade layer can exist at the same level as the service layer. Quite true, but over a period of time when the service layer gets fat with lots and lots of business specific code being written, the objects that go in and out of this layer becomes unclear, as to the core set of objects around which the whole application revolves. This loss of focus from the core objects of functionality can result in a loss of a perspective in writing new code/flow for the application, the consequences of which can be differently dangerous in varied scenarios.

To conclude,I like this layout because:

1/ It keeps a unique object being passed across layers.

2/Multiple Do’s and Do not Do’s from design perspective get constrained for the developer.

3/Gives greater and cleaner objectivity to the flow of the objects in the complete application.The service layer can be controlled as one that caters to core business and the one that is responsible for supported objects.

4/Easy refactoring capabilities and pluggable architecture.

Is it fair to partition the service layer on primary objects?Does it limit the growth of the application(and business itself)?

What do you think?