Chris Johnston

I am going to try and start writting a series of very short tutorials on some of the things that I had trouble with when I was learning enterprise Java. The first of these is on what having a Layered Architecture means and why you should implement one. Hopefully this will be the first article in a series.

Layered Architecture

Layered Architecture is a term that you hear all the time in the world of Java, but what does it mean? In a nutshell, it is about putting code into layers—one layer for all the presentation code, one layer for the persistence code, one layer for the business rules, one layer for the object model, one layer for services, and other layers. It is a way of organizing your code that carries several benefits when done correctly.

Organized Code

Why can’t I just put all my code in the same place? This works well for a few classes, but once you have a few more classes, and then a few more, and a few 100 more, you need to organize those classes somehow. Layers is one way to do this. In Java, teh word layers translates to packages. So, in order to create these layers, you simply put your code into different packages. As an example, you could create a package called com.foo.presentation and put all your presentation code into it. Here is an example list of packages for a new application:

• com.foo.presentation
• com.foo.business
• com.foo.persistence
• com.foo.objectmodel
• com.foo.services

Abstraction

The better reason for organizing your code into layers is for abstraction and encapsulation. This allows you to keep dependencies at a minimum and allows you join the layers through abstraction instead of through direct instantiation. Basically this means that you persistence layer can exist independently of any of the layers above. And the layers above call the code in the persistence layer through an interface instead of through concrete classes. In a component diagram, this means that you would have dependency arrows going down through the layers instead of both ways. Below is a diagram showing what I mean.

As you can see from the diagram, all the arrows either travel down through the layers or to the two side layers. These downward arrows represent the direction of dependencies through the application. The advantage of this is that if I build an application correctly, I should be able to swap out any of the layers and replace with entirely different code without breaking any of the other layers. So for example, if I am using Hibernate as my persistence layer, if I set up the correct interfaces I should be able to swap in something like Top Link or iBatis and DAOs and the entire application should continue to work. This is the power that a layered architecture gives you.

This is a very simple introduction to the concept of layered architecture, there are entire books that can be written on the subject. The best of which is probably Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman. This is one of those books that every software developer should read. It introduces not only Object-Oriented analysis and design using UML, but also design patterns and speaks at length about layered architectures in software development.

Feel free to leave comments on what I have written. If you have questions or issues with/about what I have written, please let me know through the comments section.

Resources and Links

• MVC and Layered Architectures in Java
• Model-View-Controller — and implementation of a layered architecture