Common Layering Schemes
Traditional two-tier client/server-based applications can be partitioned into two layers: presentation and data access. A GUI application would simply query a data source, compute, and display the information to the user. Object technology encouraged the abstraction and reuse of not only presentation logic but also business processes and data. Therefore, decoupling application logic from application presentation was encouraged and has resulted in scalable three-tier distributed systems, allowing objects defined to model business data and processes to be used across application boundaries. With the explosion of the Internet and related technologies, requirements to scale, rapidly develop, deploy, and react to business changes have made the existence of layered application architecture imperative.
The most obvious layers of an application can be partitioned into presentation, domain, and data source sections (Figure 3.4). Arguably the most important layer is the domain, where business process and state are captured. Presentation-layer objects simply consume or exercise domain objects. Data source objects defined in the data source layer simply access specific data sources on behalf of domain objects requesting or saving state.
Figure 3.4 Client/Server Layers
It is not enough to simply stipulate the layers in a graphic and expect developers to properly partition application elements into a layered architecture. Developers must implement functionality within each layer in a consistent fashion; moreover, message interaction between layers must be formalized.
Formalizing layer interaction should involve a decoupled design that includes the proper indirection in support of layer substitution. Additionally, behavior prescribed across all applications, namely, exception handling, logging, and start-up and shut-down operations, should be formalized and applied consistently.