I will go over more later but for now we will start with a simple 3 tier architecture (See Diagram Image Below):

A Simple 3 Tier Architecture Diagram

A 3 Tier Architecture Concrete Diagram

We will go over each tier and how they relate to one another with some concrete examples.

VO / DTO
Sometimes called VOs (Value Objects) or DTOs (Data Transport Objects) The purpose of this segment of the architecture is to provide a common way to move data through all the tiers. The implementation of a VO is basically similar to a Struct C++ object, a POJO in Java, a PONO in .Net, etc. which in OO (Object Oriented) Geek terms means it is an Object with attributes only; plain old accessors and mutators (getters and setters). Additionally, per the diagram, these objects have no dependencies on any of the tiers but can have interdependency with in the VO segment. i.e. VOs have no clue about what is in the presentation, domain or DAO tiers but can have relationships with other VOs. VOs also tend to have a one to one mapping with entities in the repository and mirror the fields as attributes. i.e. An Employee table with a field definition of FirstName would have a corresponding EmployeeVO with an attribute “FirstName”

Presentation / UI Tier
The Presentation or UI (User Interface) Tier is responsible for anything to do with the display and interaction of the system. The presentation tier its self can consist of its own set of architectural patterns such as MVC (Model View Controller) and is dependent on the Domain tier to handle any validation rules as well as retrieving the correct data and mapping it out for display. It is important to note that no business logic should be baked into this tier, only logic related to handle display. i.e. The Presentation tier is responsible for formatting and display currency correctly while the Domain would be responsible for calculating the amount of currencly available. This tier may use the Domain as a proxy to the DAO tier but should never call the DAO tier directly. i.e. if there is no business logic required, use a pass through call from the Domain Object to the DAO for a quick look up value but not calling the DAO directly. Since this is a 3tier architecture, transaction management also usually occurs here.

Domain / Business Logic Tier
The Domain or Business Logic tier is where where rules/calculations and behaviors related to the application/enterprise. These objects tend to directly related to the main entities in a domain model or use case diagram. The domain objects have a dependency on the DAO tier (may consist of multiple DAOs) for the persistence and retrieval of data as well as the VOs for applying calculations, validation and manipulating the data to satisfy the business needs. So why have this extra tier? Why not include the business logic in the presentation tier and save on code? If you place the business logic in the UI then you lose the ability to have code reuse as well as increase the risks of impact if you need to extend, enhance or scale out your application. One example is if you have an employee management screen that allows you to add, edit and delete employees from your system and the business decides to expose the system to a 3rd party HR vendor it is important to have the 3rd party vendor subject to the same add, edit and delete rules that your systems entry has in order to stay consistent with the business requirements. Placing these rules in the Domain tier allows both the UI and the service calls to reuse the same set of rules as well as have a single point of maintenance if the business decides to change the rules.

DAO / DAL Tier
The DAO (Data Access Object) or DAL (Data Access Logic) tier is responsible for interaction with the actual persistence of data and should not contain any business logic. It only performs CRUD (Create, Read, Update, Delete) logic by mapping data to and from the VOs. The only dependencies the DAO tier has are the physical repository (usually one or more Databases) and the VOs. *NOTE: You could still use the DAO tier for batch processing but you may incur a performance hit if marshaling data to and from VOs. In the case of batch processing I recommend taking direct persistence calls such as SQL. DAOs tend to have a one to one mapping with Entities in the repository and only return VOs of that Entity type. i.e. an Employee table would have a corresponding EmployeeDAO which performs CRUD operations on only EmployeeVOs

This post is just a brief overview of a simple 3-Tier Architecture and its make up of Tiers (Presentation, Domain and DAO with VOs as the Data Transport) If you find this post useful, please let me know and I will continue to post more.