The constrained Pattern Frame and the patterns it contains provide enough data points to begin using patterns to describe entire solutions. In fact, the quoting example from Chapter 1 can be described in terms of patterns. Recall that the requirements specified a Web-based quote application. Someone describing the architecture of the solution might say something like this:
Let’s start by looking at the quote application at the architecture level of abstraction. From the application viewpoint, the quote application is an Object-Oriented Application that is logically structured as a Three-Layered Services Application. From the database viewpoint, the application is based on the OLTP processing model. From the infrastructure viewpoint, the hardware and network architecture are based on Four-Tiered Distribution, which calls for separate physical tiers for Web server and application server functionality. And finally, from the deployment viewpoint, the team has created a Deployment Plan to map components to servers, based on a Complex Web Application.
This concisely describes the architecture of the solution across all four of the viewpoints to anyone familiar with the referenced patterns. Continuing down one level of abstraction, you can see how someone might describe the design of the system:
From the application viewpoint, let’s consider each layer of our Three-Layered Services Application separately.
The presentation layer is structured around a Web presentation framework based on Model-View-Controller (MVC). Although MVC provides a level of separation between business and presentation logic, each page contains a great deal of common logic. To eliminate this redundancy, we use a Page Controller to render common headers and footers and set a friendly display name for the user.
The business layer holds the Customer, Quote, Order, Line Item, and Inventory domain objects. The domain objects are realized using Table Module [Fowler03] because speed of development is a key requirement. The Complex Web Application Deployment Model calls for separate Web and application tiers. Therefore, the two tiers communicate through a Broker. Business entities, acting in the role of Data Transfer Objects [Fowler03], are used to encapsulate the information traveling between the two tiers.
The data layer uses a Data Table Gateway [Fowler03] to access the OLTP database subsystem and a number of data access components to support the persistence requirements of the domain objects.
From the infrastructure viewpoint: to meet the operational requirements of the business, we build on the basic Four-Tiered Distribution model by adding Load Balanced Cluster and Failover Cluster. Responding to a requirement calling for a high level of concurrent users, we added load balancing to our Web tier. To meet availability requirements, we added clustering to our database tier.
The description could continue on to describe the data and deployment viewpoints at the same level of abstraction. To continue, instead, down one more level of abstraction, you can see how someone might describe the implementation of the solution:
Let’s look at the solution from the application viewpoint. The solution is built using Microsoft .NET technology. The presentation layer is based on the Web presentation framework that is built into ASP.NET. ASP.NET simplifies the implementation of Model-View-Controller with the built-in code-behind page feature. We use the built-in Page Controller mechanism in ASP.NET to implement our presentation logic. The domain objects in the business layer are managed .NET objects. Because the presentation layer and business layer are deployed on separate tiers, we use Implementing Broker with .NET Remoting Using Server-Activated Objects. Finally, the data layer is based on the ADO.NET classes within the .NET Framework to provide database access. The Table Modules and business entities are constructed using the DataSet component of ADO.NET. The remainder of the Data Access Components are provided by the Microsoft Application Blocks for .NET building block.
From the infrastructure viewpoint: Microsoft SQL Server , running in a failover cluster, is used for the OLTP database subsystem. Microsoft Network Load Balancing clusters provide load balancing between Web servers.
All of these conversations make frequent references to patterns. This can be daunting at first, but when you understand the patterns used, you realize that even this brief description gives you a detailed understanding about how the system works. Notice that you gained this understanding without having to wade through reams of documentation or step through endless lines of code. The communication benefits of patterns become clear if you imagine how much more work would be involved in describing the solution without using patterns.