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, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.|
|Are you being asked to manage a project with unclear requirements, high levels of change, and/or a team using Extreme Programming or other Agile Methods? If you are a project manager or team leader who is interested in learning the secrets of successfully controlling and delivering agile projects, then this is the book for you. From learning how agile projects are different from traditional projects, to detailed guidance on a number of agile management techniques and how to introduce them onto your own projects, we have the insider secrets from some of the industry experts – the visionaries who developed the agile methodologies in the first place. Managing Agile Projects is edited by Kevin Aguanno, a noted speaker and educator on agile project management, and includes contributions from many noted figures in the agile movement.|
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.