Tiers for Logical Application Separation

This is the first of three articles on tiers in software development. The next two will focus on data transfer and exception processing.

Current thinking in software architecture is that applications should be designed and implemented in clear tiers. Think of a chocolate layer cake. The icing is the GUI tier - the one you see. Each layer below is a tier providing unique functionality.

Examples

A standard PHP web application is a single tier design. The same code that accesses the database also displays the pages. From another perspective it is a 3-tier design with the browser providing the GUI tier and the database engine the persistence tier. Still, the developer can only change the single central tier.

A client/server system is a clear 2-tier design. There is a clear division between the 2 parts of the application - to the extent that they are usually running on different systems.

N-tier systems are less easy to see from the outside as it is a development model rather than a physical separation.

An N-Tier Pattern

I divide an application into tiers and tiers into layers. Really there is no difference except for logical grouping.

1. GUI Tier
   1. GUI display layer - responsible for display and retrieval of data only. It expects information ready to display and passes information back as it comes from the user. In a web application it is code and information passed to the browser for rendering. Because it is the only part of the application that will be operating locally to the user, it may include some code for validation of input and manipulation of display for output.
   2. GUI support layer - Manipulates information as the program sees it to produce information that the browser renders and the user sees. In traditional web server applications the JSP or ASP is the prime GUI support tier.
   3. GUI transfer layer - is the primary interface with the next tier. Information to be displayed is consolidated here and formatted into the form to be placed on the screen. A date object, for example, will be turned into a string to be displayed. The same goes for the reverse direction. When the user enters information, this is the second level of validation as strings are translated to internal form.
2. Business Logic Tier
   1. Service Layer - The latest buzz-word is SOA (Service Oriented Architecture). This is the layer that supplies the exported services, and can talk with the GUI tier above, a fat client or a Tuxedo interface for a remote request from another server. The service layer should not be involved in the infrastructure required to deliver the service. It's prime responsibility is to respond to requests, recieving and sending messages as simple data structures without code or other ties to the underlying system (DTO). It will need to validate parameters and apply security as required.
   2. Definition Layer - Here the definitions for business logic - as defined in the design documents - have been translated to code. Code here should be simple, clean and clear - able to be compared one-to-one with the design documents. Don't confuse the definitions with implementation, and don't validate parameters, catch and process exceptions or any other implementation code that can 'muddy the waters' when reviewing business process. Each method should be a clear list of actions with branches and loops.
   3. Implementation Layer - This is where the business work is done. Each of the actions used in the matching Definitions layer will be implemented with all the nasties of exception processing, data retrieval and consolidation. While the code in this layer will be dirty with detail, if the business instructions in the definition layer are finely grained, then methods should not be too large or hard to follow. Any refactoring to make use of common code should be done at this layer rather than the Definitions layer, for the sake of clarity on the higher tiers.
3. Persistence Tier (Database, mail, IPC and such)
   1. Interface Layer - This is effectively an internal service layer. For a database package it would encompass the domain model representation, providing enough information in a single method to satisfy service layer requests without loading to much additional information from the tables. The service layer should not know about persistence internals, so this layer provides a level of separation.
   2. Implementation Layer - The implementation layer more finely-grained than the interface layer. It's typically one-to-one with the database tables or other interface services. It's often provided by external packages (i.e. hibernate or javax.mail), although it can also include system-local interfaces to external packages.
   3. Helper Layer - In the persistence tier above all others, the various tables and interfaces referred to in the implementation layer will require common code for processing. In a full OO design these would be part of the super class. Because tables and interfaces often use external packages that cannot always be subclassed, common support code will need to be in separate objects. Put these in a separate Helper layer for clarity.