The Meaning of Architecture
At this point, it is noticeable that there is a more significant relationship between architecture and component, so that a better definition can be made:
The architecture of a software system is the form given to a system divided into components, specifying their arrangement and interaction between these components.
This architecture is not rigid and changes over time due to changes in requirements, design criteria and other circumstances, so it represents a constant balance.
- Supports the system life cycle: Aims to facilitate the development, deployment, operation and maintenance phases.
- It does not focus on the operational details of the system.: It bears little relation to the operation of the system, only at a passive and cosmetic level.
- Keeps options open: In the face of changing objectives, we can resort to design principles (SOLID Principles and Component Principles) in order to maintain maximum flexibility and have a variety of alternatives at our disposal.
- An architecture decomposes the system into components: This decomposition ensures the stability and integrity of the system, while allowing the teams to work independently on each of the components.
-
An architecture considers deployment challenges up front: Choosing a high level of deployment without having previously considered all aspects can result in a waste of money.
-
One architecture facilitates immediate deployment: The architecture does not depend on configuration files, nor does it depend on the organization of directories or files.
The operation can be analyzed from 2 perspectives: operation performance and cognitive effort.
- An architecture has little bearing on the performance of the operation.: Performance optimization is a detail that can be afforded by well-isolated components, and can be addressed by adding more hardware and switching between different deployment strategies as the system's operational needs change.
- An architecture is more related to cognitive effort.: Understanding what the system does is critical at the operational level and involves highlighting key use cases, functions and behaviors that are visible to developers.
- An architecture reduces risk by adding features or repairing defects: Decomposition into well-isolated components facilitates maintenance tasks.
An architecture divides the system into horizontal and vertical layers for:
- Promoting independent development: It allows the organization of development teams to address each component independently.
- Promote independent implementation: Allows to change horizontal layers or vertical layers (use cases) in a simple way.
An architecture is not deployment details, components can be decoupled to such a degree that they can change between the different levels (source, deployment and service). Therefore, a good architecture will allow moving back and forth between the different levels.
Consequently, if you thought that monoliths, standalone deployable units, Service Oriented Architecture (SOA) and microservices are architectures or part of your architecture, they are not and act more as a means to support the demand required by the system, i.e. they are deployment strategies.
At this level, we control the dependencies of the source code modules to keep them decoupled. Also, all these modules are integrated into a single executable that operates in a single address space, known as Monolith.
-
Large, single, tightly coupled unit: Humorously, the "Monolith" is represented as a "spaghetti plate" to highlight the problems of lack of modularity and the difficulty of scaling and maintaining code in large projects. However, a good monolith design maintains a modular and organized structure, even within a single unit; so the above problems are a product of bad design.
-
Modular Monolith: This concept seems to be a patch on the previous idea, because it justifies the idea that a monolith lacks modularity, when in fact the ability to be modular is inherent to a good architecture and is not defined by a deployment strategy. What is remarkable at this point is the ability to encapsulate parts of the code to make a distinction between what you want to show and what you don't; for example, we find these features present in:
- Java 9 and its module system
- Kotlin with its internal keyword
- Gradle and its module system
At this level, some components are decoupled into independent deployable units, so they run in different processes and communicate through inter-process communication (IPC), sockets or shared memory.
At this level, the components have been reduced to simple independent execution units that communicate via network packets.
