Three-tier architecture in a nutshell II: designing the middle tier

A personal note to start. I'd been meaning to write this article for at least a year and a half. You need to be in the mood for certain things, but I never expected the article, or at least its outline, to be cobbled together on a bus from Prague to Písek on a Friday evening.

When we discussed three-tier architecture, we stressed that the design of the middle tier, sometimes called the application layer, deserves the most attention. The application's middle tier should be divided horizontally into sublayers. I'll call those sublayers “layers” for the rest of the article.

Layers should depend on one another through interfaces, so implementations can be changed easily later. Separating the layers also makes unit testing easier. There are essentially three basic layers.

UI/RPC layer
Service layer
DAO layer

Archive image in Three-tier architecture in a nutshell II: designing the middle tier, figure 1

Full-size image (29 KB)

UI layer/RPC bridge

The UI layer or RPC bridge sits between the client's communication protocol and the internal structure of the application. It uses only the service layer directly. It translates the request into an internal call and returns the data in the appropriate format.

UI layer

This part works with a web browser and returns HTML in response to a request. The UI layer should follow the MVC (Model-View-Controller) design pattern.

RPC bridge

This layer acts as an intermediary for a particular RPC implementation. Essentially, it exposes the service layer for remote calls, as a web service for example.

Service layer

The service layer, also called the business layer, implements application logic. It is where the application's algorithms live. This layer works directly only with the next layer down, which provides data.

Data access layer

The data access layer deals exclusively with the data store. The store might be a relational database, a file system or another system. This layer contains only the logic for working with that particular data source. For a relational database, the layer uses the conventional JDBC API or an object-relational API.

Domain model

The application's domain model holds the layers together. It represents the relationships between entities in the system as objects. An online store, for example, has entities such as an order, the customer placing it, a product and an invoice. Represented as objects, these entities make up the application's domain model.

All the layers work with the domain model according to their roles. The DAO layer might turn a relational database query result into an object graph. The service layer processes the resulting graph, for example by checking whether the product is in stock and sending an email. The UI layer shows the user the result of the requested action.

Cross-cutting concerns

Transactions, authorization and logging cut across the layers. It therefore makes little sense to bury them deep inside the application. Non-invasive techniques such as metadata (annotations or descriptive XML) and AOP (aspect-oriented programming) are much more suitable.

Transactions

You can define transactions at the service or DAO layer and propagate them downward. You can define a transaction programmatically, by calling the transaction API from application code, or with metadata, which is known as a declarative definition. Declarative transactions suffice in 95 percent of cases. The rest can use the transaction API directly.

Authorization

Authorizing individual method calls is another classic concern you can define declaratively with metadata, without modifying application code. Method-level authorization may not always be needed, though.

Logging

Logging at application-layer boundaries, like authorization, may or may not be necessary. AOP works well for layer-level logging, such as audit logging. For logging that traces program execution, of course, you'll need to include a logging API in the application code itself.

Choosing technology

The basic rule when choosing technology for the middle tier is that it should never dictate the application's architecture. I won't promote a specific technology here. This article is about architecture. The technology is an implementation detail hidden behind the business interface…

November 11, 2004, Dagblog, Three-tier architecture in a nutshell I