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.

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.

Layer	Description	Skillset
Interface	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: User interface design skills Ability to work closely with stakeholders For system interfaces: API design skills Legacy analysis skills
Domain	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.	Analysis skills to identify domain classes Design skills to determine how to implement the domain classes Domain modeling skills, in particular UML class modeling
Process	The process layer implements business logic that involves collaborating with several domain classes or even other process classes.	Analysis skills to identify process classes and process logic Design skills to determine how to implement the process classes Modeling skills, in particular activity modeling, flow charting, and sequence diagramming
Persistence	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.	Object/relational (O/R) mapping Architectural skills so you can choose the right database encapsulation strategy Modeling skills, in particular class modeling and physical data modeling
System	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.	Analysis skills to identify what needs to be built Architectural and design skills to determine how to implement the classes Modeling skills, in particular class modeling, sequence diagramming, and state modeling

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.

Source

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.

Class Type Architecture: A Strategy for Layering Software Applications

Source

Suggested Reading