A common architectural strategy, some might call it a pattern, is to layer
the architecture of a system into several layers/strata. Some strategies simply
define N layers stacked on top of each other where layer J interacts only with
layers J-1 and J+1. That's an interesting theory, and it clearly makes
sense from a logical point of view, but in practice I've
found that it isn't quite so simple. Figure 1
presents a high-level layering strategy for a software application.
The various layers are represented by the rectangles and collaboration
between layers by the arrows. The primary name of a layer is
indicated first, and other common names in parenthesis.
Figure 1. Layered class type architecture.
I originally used the term "class type" because I first started with this
approach using object-oriented (OO) technology, although since then have used it
for component-based architectures, service oriented architectures (SOAs), and
combinations thereof. Throughout this article I still refer to classes
within the layers, although there is absolutely nothing stopping you from using
non-OO technology to implement the layers. The five layers are summarized
in Table 1, as are the skills required to successfully
work on them (coding is applicable to all layers so it's not listed).
Table 1. The 5 Layers.
For system interfaces:
Collaboration within a layer is allowed. For example, UI
objects can send messages to other UI objects and business/domain objects can
send messages to other business/domain objects. Collaboration can also occur
between layers connected by arrows. As you see in
Figure 1, interface classes may send messages to domain classes but not to
persistence classes. Domain classes may send messages to persistence classes,
but not to interface classes. By restricting the flow of messages to only one
direction, you dramatically increase the portability of your system by reducing
the coupling between classes. For example, the domain classes don't rely on the
user interface of the system, implying that you can change the interface without
affecting the underlying business logic.
All types of classes may interact with system classes. This is because your
system layer implements fundamental software features such as inter-process
communication (IPC), a service classes use to collaborate with classes on other
computers, and audit logging, which classes use to record critical actions taken
by the software. For example, if your user interface classes are running on a
personal computer (PC) and your domain classes are running on an EJB application
server on another machine, and then your interface classes will send messages to
the domain classes via the IPC service in the system layer. This service is
often implemented via the use of middleware.
It's critical to understand that this isn't the only way to layer an
application, but instead that it is a very common one. The important thing is
that you identify the layers that are pertinent to your environment and then act
I originally wrote about the class type architecture in
Object Applications That Work, a Jolt-productivity award winner, but have
updated the concept since. Most of the material for this article is excerpted from Chapter 10 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.