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.
|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:
For system interfaces:
|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.|
|Process||The process layer implements business logic that involves collaborating with several domain classes or even other process classes.|
|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.|
|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.|
|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 presents a full-lifecycle, agile model driven development (AMDD) approach to software development. It is one of the few books which covers both object-oriented and data-oriented development in a comprehensive and coherent manner. Techniques the book covers include Agile Modeling (AM), Full Lifecycle Object-Oriented Testing (FLOOT), over 30 modeling techniques, agile database techniques, refactoring, and test driven development (TDD). If you want to gain the skills required to build mission-critical applications in an agile manner, this is the book for you.|
This book demystifies enterprise architecture and helps organizations recognize real business value through effective implementation.
We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.
This site owned by Ambysoft Inc.