Class Type Architecture: A Strategy for Layering Software Applications
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.
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).
|This layer wraps access to the logic of your system. There are two categories of interface class – user interface (UI) classes that provide people access to your system and system interface (SI) classes that provide access to external systems to your system. Java Server Pages (JSPs) and graphical user interface (GUI) screens implemented via the Swing class library are commonly used to implement UI classes within Java. Web services and CORBA wrapper classes are good options for implementing SI classes.
|For user interfaces:
For system interfaces:
|This layer implements the concepts pertinent to your business domain such as Student or Seminar, focusing on the data aspects of the business objects, plus behaviors specific to individual objects. Enterprise Java Bean (EJB) entity classes are a common approach to implementing domain classes within Java.
|The process layer implements business logic that involves collaborating with several domain classes or even other process classes.
|Persistence layers encapsulate the capability to store, retrieve, and delete objects/data permanently without revealing details of the underlying storage technology. often implement between your object schema and your database schema and there are various available to you.
|System classes provide operating-system-specific functionality for your applications, isolating your software from the operating system (OS) by wrapping OS-specific features, increasing the portability of your application.
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 accordingly.
I originally wrote about the class type architecture in Building 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.
This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.