Breaking it down further (Application Tier)

As mentioned in my earlier posts, the logical tiers that make up "Application Architecture" are (in my mind) the Client Tier, Application Tier, and the Integration (or Data) Tier. Some of the application architecture tiers can be further broken down into logical layers.

As application designers/developers/architects, we are generally most concerned with the Application Tier, because that is where the bulk of most application logic and functionality reside (with the notable exception in the Web 2.0 world that is moving more and more presentation and business logic down to the client tier, but that is another matter).

Application Tier
For design purposes, the Application Tier can then be further broken down into into several discrete Application Layers, which provide a logical separation of concerns for our application.

As you can see, the application layers include:

• Presentation Layer
• Business Layer (Services and Objects)
• Integration/Data Layer

Presentation Layer
The aptly named presentation layer is pretty much exactly what you would expect.  It is the presentation of the application to the user, delivered generally as a group of UI components as well as UI Process components.  It basically orchestrates the response to any application requests, which for web applications are generally HTTP requests originating from a browser (web service applications are a bit different in implementation, but similar in concept).

Depending on the nature of the application and the technologies in place, this layer can be delivered as a wide variety of components.  Regardless of the technologies used, one over-riding pattern that is generally considered the best approach for managing the interactions between UI and UIP components is the Model-View-Controller (MVC) pattern, whose responsibilities include:

• receiving and handling user events, acting as the overall request "controller"
• calling out to service classes to build the "model" data for the response
• creating appropriate "view" responses and sending to the caller

An interesting point that is often overlooked is that the Presentation Layer is generally the only "stateful" layer within the application architecture (since it is responsible for managing the user sessions/state). Ideally, the Business and Integration/Data Layers of an application are "stateless" (to open up the possibility for re-use of these components by other clients/callers).

Business Layer
The business layer is where the 'guts' of the business logic is stored.  This is generally where the real functionality of the application is implemented.  Components in this layer are generally structured around real-world business concepts, and encapsulate the business logic (or business rules) for the application functionality being delivered.

Many times, these functions are broken down into more logical services (aka Business Services), and delivered through some sort of application facade, often referred to as a Service Interface.  Now, this doesn't necessarily mean that it uses Web Services, but that is one method for having a more technology-agnostic approach for developing business functionality and making it available to applications leveraging multiple technology stacks.

Similarly, there are often software components that represent their real-world counterparts that are often called the Business Objects (like Invoice, Employee, Customer, etc.).  These are generally just containers for managing related data and presenting it in a meaningful way.  While these objects often originate in the Business Layer, they can be used to pass the structured data between layers (to the Presentation Layer, for example).

Integration/Data Layer
The Integration Layer is the interface for the Business Layers to interact with any enterprise systems (including databases).  This is where the distinction between Layers and Tiers is most useful.  Most business applications are centered around delivering "data", which often resides in some sort of back-end repository, like a database (although there are many other possibilities, like ERP systems, LDAP trees, Web Services, etc.).  The components in the integration layer (or data layer) are responsible for exposing the data from these repositories to the business layer.

The Integration Layer is often implemented using Data Access Objects (DAO) for database access or Adapters for other enterprise integrations (Web Services, RSS, etc.).  Continuing the practice of separating design from implementation, one preferred approach here is to define an interface for the DAO, like StudentDao, and then provide an appropriately named implementation, like JdbcStudentDao (if JDBC based, could also be HibernateStudentDao).

As just mentioned, Object-Relational-Mapping tools (ORM) like Hibernate are another option for the Integration/Data Layer, but they can add a level of complexity that is not always required for business applications (particularly those that are "view-only").

Stored procedures are an interesting case., and can complicate the logical separation of layers and tiers.  While the stored procedures can often contain "business logic" that would be considered part of the Application Tier, the actual implementation (code) resides within the database itself - on the Data Tier.  This murkiness is generally undesirable, and as such I generally prefer to avoid stored procedures when possible.  There are cases when their use makes sense, but keep in mind that it can complicate your application architecture.