Monolithic Architecture
A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications.
Planning
Designing
Developing
Monolithic Architecture
A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications. The word “monolith” is often attributed to something large and glacial, which isn’t far from the truth of a monolith architecture for software design. A monolithic architecture is a singular, large computing network with one code base that couples all of the business concerns together. To make a change to this sort of application requires updating the entire stack by accessing the code base and building and deploying an updated version of the service-side interface. This makes updates restrictive and time-consuming.
Monoliths can be convenient early on in a project’s life for ease of code management, cognitive overhead, and deployment. This allows everything in the monolith to be released at once.
Benefits of a monolithic architecture
Organizations can benefit from either a monolithic or microservices architecture, depending on a number of different factors. When developing using a monolithic architecture, the primary advantage is fast development speed due to the simplicity of having an application based on one code base.
The advantages of a monolithic architecture include:
Easy deployment – One executable file or directory makes deployment easier.
Development – When an application is built with one code base, it is easier to develop.
Performance – In a centralized code base and repository, one API can often perform the same function that numerous APIs perform with microservices.
Simplified testing – Since a monolithic application is a single, centralized unit, end-to-end testing can be performed faster than with a distributed application.
Easy debugging – With all code located in one place, it’s easier to follow a request and find an issue.
Challenges of a monolithic architecture
As with the case of Netflix, monolithic applications can be quite effective until they grow too large and scaling becomes a challenge. Making a small change in a single function requires compiling and testing the entire platform, which goes against the agile approach today’s developers favor.
The disadvantages of a monolith include:
Slower development speed – A large, monolithic application makes development more complex and slower.
Scalability – You can’t scale individual components.
Reliability – If there’s an error in any module, it could affect the entire application’s availability.
Barrier to technology adoption – Any changes in the framework or language affects the entire application, making changes often expensive and time-consuming.
Lack of flexibility – A monolith is constrained by the technologies already used in the monolith.
Deployment – A small change to a monolithic application requires the redeployment of the entire monolith.
Layered (N-Layer) Architecture
The layered architecture pattern is the most commonly used architecture pattern. Known as the n-tier architecture style or the multi-layered architecture style.
Organize the components of an application with similar functionalities into horizontal logical layers. Each layer performs a specific role within the application.
Still using Monolithic architecture separating horizontal logical layers, components are interconnected but don’t depend on each other.
Organizing code for separation of concerns
Layers of isolation that layers can be modified and the change won’t affect other layers
Components of a Layered Architecture
Presentation – Responsible for user interactions with the software
system, for example, a web app.
Application / Business Layer – Handles aspects related to accomplishing functional requirements including use case implementations.
Database Layer – Responsible for handling data, databases, such as a
SQL database.
Design principles - Separation of Concerns (SoC)
Separation of concerns(SOC) is one of the core software design principle
Separation of concerns is a design principle for separating a computer program into distinct sections
Isolate the software application into separate sections, manages complexity by partitioning the software system
Distinguish between the concepts of layer and tiers with certain responsibilities.
Elements in the software should be unique
Limits to allocate responsibilities
Low-coupling, high-cohesion
Design principles - SOLID
Single Responsibility Each of your components or modules should responsible only one functionality.
Open-Closed Principle When we design the system, it should able to extend without changing existing architecture.
Liskov Substitution Principle Systems can be substitute each other easily. In our case we can use plug-in services that we can shift them easily
Interface Segregation Principle States that no code should be forced to depend on methods it doesn’t use.
Dependency Inversion Principle States that high-level modules should not depend on low-level modules; both should depend on abstractions.