Read this article if you want to learn how to layer software centric server-based system. This article is not geared towards a specific technology and the concepts presented can be applied to any type of server-centric architectures, such as J2EE or .NET It does – however – have a focus on server-side processing such as web-based, rich-client or service-oriented architectures.
The layer diagram is a diagram also commonly found in IT Architectures. It has uses in many IT domains, not just Software Architecture. This article will – however –primarily focus on the Software Architecture view, and not consider others.
The layer diagram is a particularly popular diagram for a number of reasons. Two important ones for me are:
- It provides an easy to read logical view of the software architecture to be put into place, and
- It can be used to show how the technical components (layers, tiers and data) are tied together with the functional (functions and business objects) components of a software system.
In this article I am going to outline the notation I have come to use in software development projects of that kind. It may be mixture of a number of notations but it assists well in describing the logical view of a software system.
Diagrams of this kind can be drawn with any tool. Often I simply use paper, flipcharts or white-boards to develop layer diagrams and usually only document the final view with a tool.
2. Typical Use
This diagram is typically used to develop the high-level design for a software-centric system to demonstrate
- how an application is structured into logical (technical) components
- where major technical subsystems are placed in the architecture
- how functional components of the system are tied with the technical components
- how the data is dealt with by the software system
3. Notation used in Layer Diagrams
While I tried to outline the steps in a serial manner, the development or a layer diagram will always be iterative where you will most likely iterate through the outlined steps a number of times.
Step 1 – Identify and Define Tiers
As a first step identify the tiers of the system. This primarily depends on the non-functional requirements. In addition it will – however – also be influenced by the functional requirements. Therefore it is important not to leave them out in the thought process.
Briefly identify and describe the responsibilities each tier has.
Step 2 – Identify and define layers and place technical components
In a second step identify the layers. This process is mainly driven by non-functional requirements and best practices. Briefly define and describe the responsibilities each layer has.
Once the layers have been placed, identify important technical (framework) components and place them into the appropriate layer of your architecture. Examples are: asynchronous processes, caches, security, and others.
Step 3 – Place functional components and Data
Always keep in mind how the technical platform created will cater to the needs of the functional requirements. While large parts of the technical architecture can be developed based on best practices, you will always need to make minor adjustments based on functional needs.
What I have found most useful it to finally place functions into the layer diagram. This helps to:
- Identify technical components required to bridge between the technical layering and the functional aspects. Specifically, how responsibilities need to be placed into the layers so that the functional needs can be catered to appropriately.
- Identify how data is dealt with in the architecture. Typically each layer will deal with the same data differently in each layer.
Notes on developing responsibilities for layers
I will start at side of the client request and define what type of service the server needs to provide to the client. From there on I will move to the data layer on a layer by layer basis and define which service the next layer needs to provide to the previous layer.
Looking at the figure above, this could be something line: the web layer uses Services in the service layer, the service layer uses business logic and/or business rules in the logic layer, the logic layer uses data access objects in the data access layer which read and persist data.
Notes on placing the data
Do not forget about placing data and that data is not equal to data. It is important to note that different layers will operate on the same data but will often require the data to be in a different format. For example:
- The data in the data layer is stored in a relational database schema (if you are using a relational database).
- The data access layer will operate on an object representation of that data layer often with the help of a object-relational-mapping component such as Hibernate. Therefore the data objects need to be a much closer representation of the database schema itself. I often call them data access layer POJOs.
- The other layers will in most cases operate on an object representation that more closely reflects the reality of the domain the software is developed for. This is what I usually call Business Objects (BOs).
[Pic2010] Pichler, M. 2010, “Diagram: A more complex Layer Diagram (example)”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/
[Pic2010] Pichler, M. 2010, “Diagram: A more complex Network Diagram (example)”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/
[Pic2010] Pichler, M. 2010, “Diagram: The Network Diagram”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/
[Pic2010] Pichler, M. 2010, “Knowledge Nugget: What is a Layer in Software Architecture?”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/
[Pic2010] Pichler, M. 2010, “Knowledge Nugget: What is a Tier in Software Architecture?”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/
[Pic2010] Pichler, M. 2010, “On documenting Software Architecture (for Business Applications)”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/
Copyright © 2010 Michael Pichler