What Is Software Architecture?
We frequently hear people talk about software architecture, but what does this mean? Is it really different from design? If so, what exactly is it?
Join the DZone community and get the full member experience.Join For Free
What is software architecture? In the previous article, What Is Architecture? we stated that architecture is about structural elements and connective elements.
Let's talk about these in regards to a software system. In our next article, we'll talk about good and bad architecture.
Structural elements in software are layers that support the other layers in the system:
The language libraries are built on the functionality provided by the O/S.
The functionality of the software product is built on the language libraries.
Third-party libraries that you are using are built on the previous two layers.
Your code is built on all the previous layers.
So, any program you build has at least the following structural elements:
In a well-designed system, your code will also break into layers specific to the application that you are building. Each layer ideally only depends on layers underneath it. Otherwise, you will have circular references, a signal that there is a challenge or that something is wrong.
Every software system has connective elements that communicate across the different layers. Often, third-party libraries are shared services that provide core services like data structures (XML, JSON, etc.), logging, debugging, and other services.
Inside your code, you will also have shared services that are used by every layer. This is diagrammed as follows:
Layers 1, 2, ..., N represent the layers in your code and the share services are shown vertically as they cut across all the layers. Layer N represents the UI layer of the system and the functionality at that layer depends on all the layers below it.
When people talk about software architecture, they are not just talking about the structure of the code. Often, people are talking about the machines and O/S components as well. So, for example, when people talk about the LAMP architecture, they are talking about:
The O/S, i.e., Linux.
The web server: Apache, running on Linux.
The database: MySql, running on Linux.
The code: PHP running on the MySql database using services from the O/S.
Note: The PHP layer is further broken down like the diagram above in the Structural Elements section.
The LAMP architecture involves structural elements. Connective elements are simply the ones created inside the PHP layer or generally provided by the O/S.
So, when relevant, architecture includes:
All support services, i.e., webserver, database, etc.
The high-level applications that are written by you or a third-party.
General Software Architecture
For the structural elements of software, we are talking about layers. Those layers can be relative to the O/S, such as how the O/S communicates with support services (web servers, databases, etc.), or how your applications communicate with support services and the O/S.
Within your application there are different layer interactions:
How your base layers are built on the APIs of your language and the 3rd party libraries that you have installed.
How you have broken up your layers to communicate with the different parts of your software.
The main structural elements of any model-view-controller (MVC) program looks somewhat like this:
The model layer (AKA business layer) is built on third-party APIs and O/S APIs.
The view layer (AKA GUI layer) is built on third-party GUI APIs.
The data layer is built on database APIs.
All of the APIs that you are using are based on the standard APIs of the language that you are using.
Changing languages requires that every layer above it be reconsidered.
This means that if you change languages and some third-party API must be changed, then the layer above also needs to be changed.
The strict separation of layers means that you can change a third-party API and only a single layer of the MVC system will be affected.
Often, developers color between the lines, and a change of a third-party library causes quite a bit of pain as the layer infractions are found.
Not having enough of a business layer will be problematic because it is one of the main separating structures between your view/GUI, and data layers.
People discover lacking business layers when they change their database APIs or databases and have the problems propagate all the way through the GUI.
Often, when business functionality is built into the model/GUI layer, then that functionality is lost and needs to be recoded when a new GUI API is used.
Connective software elements are used to shuttle data between the structural layers of the system. These connective elements are generally available everywhere (although they can be limited to a few layers).
Easily understood connective elements are those used for debugging and logging. These elements are available universally. Debugging and logging routines can be made available in all layers without worrying about layer dependency.
Other connective elements are most easily recognized because they are routines shared across layers of the architecture. More specifically, they are the libraries/modules that are included in multiple layers of the program.
Published at DZone with permission of Dalip Mahal, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Competing Consumers With Spring Boot and Hazelcast
RBAC With API Gateway and Open Policy Agent (OPA)
File Upload Security and Malware Protection
Getting Started With the YugabyteDB Managed REST API