Design principles of Monolithic Architecture — KISS, YAGNI, DRY
Published: 2022-09-06 13:08:40

In this part I'm going to see some example of Reference architectures for Monolithic Architectures.

You can imagine that I'm building an e-commerce application that takes orders from customers, add to basket and checkout the order and so on.

Lets see example Reference Monolithic Architectures.

## Reference Monolithic Architecture 1

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/azz76hg6dcyifzgqpjx7.png)

The application can include several components like GUI and business logics and database persistence layers. The application is deployed as a single monolithic application.  For example, a Java web application consists of a single WAR file that runs on a web container such as Tomcat. You can run multiple instances of the application behind a load balancer in order to scale and improve availability.
As a result this solution has a number of benefits:
- Simple to develop — you develop in single code base
- Simple to deploy — you simply need to deploy only the WAR file
- Simple to scale — you can scale the application by running multiple copies of the application behind a load balancer

## Reference Monolithic Architecture 2
Here is, I can see different illustrations, again e-commerce application.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5paqau225gdckq10t3l6.png)

## Evolve Reference Monolithic Architectures**
And the last one shows how to evolve monolithic architecture.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8yxbf8611qttv6fksaea.png)

You can see in this picture, the evolution of monolithic architecture. So its start with standalone 1 application server and database. After that I can split Client application, after that split the business logic and data access and last I split services components in monolithic application.

So as you can see that I will also follow these example reference monolithic architectures and principles and design our own e-commerce application.

## Design principles of Monolithic Architecture — KISS, YAGNI, DRY
**DRY Principle**
DRY is stands for “Don’t Repeat Yourself”
_Every piece of knowledge must have a single, unambiguous, authoritative representation within a system._
This means that, you must try to maintain the behavior of a functionality of the system in a single piece of code, it should not have duplicated code or design item. It’s easier to maintain a code or system that is only in one place, because if you need to change something in the code or system, you just need to change in one place.

**KISS Principle**
KISS is stands for “Keep It Simple, Stupid”
This principle says about to make your code or system simple. You should avoid unnecessary complexity. A simple code it’s easier to maintain and easier to understand. You can apply this principle in the design and in the implementation of the code. You should eliminate duplicated code, should remove unnecessary features, use names for apis and methods that makes sense and matches their responsibilities.

You also should separate the responsibilities of your applications and the responsibilities from the layers of the systems. Most systems work best if they are kept simple rather than making them complex designs; therefore, simplicity should be a key goal in design and unnecessary complexity should be avoided.

**YAGNI Principle**
YAGNI is stands for “You Ain’t Gonna Need It”.
Sometimes, I try to think way ahead, into the future of the project, adding some extra features “just in case we need them”. This is Wrong! I don’t need it and in most of the case I can say YAGNI = “You Aren’t Gonna Need It”. This principle is similar to the KISS principle, both of them aim for a simpler solution. The difference between them is that YAGNI focus on removing unnecessary functionality and logic and KISS focus on the complexity.

So with following these principles, I will start to design our e-commerce application architecture. Remember that a clean system, it’s easier to main, easier to understand and for sure it will save your time when you need to change or implement something.

## Design the Monolithic Architecture — E-Commerce App — KISS & YAGNI
In this part I'm going to design our e-commerce application with the monolithic architecture step by step. I will iterate the architecture design one by one as per requirements.

In every case, before we design the architecture, We should always start with writing down FRs and NFRs. So lets write down FRs.

**Functional Requirements**
- List products
- Filter products as per brand and categories
- Put products into the shopping cart
- Apply coupon for discounts and see the total cost all for all of the items in shopping cart
- Checkout the shopping cart and create an order
- List my old orders and order items history
Lets write down N-FR.

**Non-Functional Requirements**
- Availability
- Scalability
Its good to add principles in our picture in order to remember them always.

**Principles**
- DRY
- KISS
- YAGNI
We are going to consider these principles when design our architecture.
Now we can consider to Database and Components of e-commerce application.

**Database**
- Database will be single relational database — RDBMS.

**Components of E-Commerce**
- Shop UI
- Catalog Service
- SC Service
- Discount Service
- Order Service
With following all these considerations, we can design our E-Commerce Monolithic Architecture with applying tech stack as below image;

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/354sqk3jx6cugeactkmf.png)

As you can see that all modules of this traditional web application, such as Shop Front UI, Catalog Service, SC Service, Discount Service and Order Service, are single artifacts in the container.
This monolithic application has a massive codebase that includes all modules. If you introduce new modules to this application, you have to make changes to the existing code and then deploy the artifact with a different code to the Tomcat server.  We can develop Java application and output to single WAR Artifact. We can use Oracle or PostgreSQL for our e-commerce monolithic database.

**Communication of Components — E-Commerce App — Monolithic Application — Inter-Process Communication**
As you know that, monolithic application sitting in the same server with all modules.  So we don’t need to make any network call. So it is very easy and fast to communicate between modules of our E -Commerce Monolithic Application.
The communication will be INTER-PROCESS COMMUNICATION.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9stk41pvdtnx2o6dgnkj.png)

Inter-process communication is the mechanism provided by the operating system that allows processes to communicate with each other. So that means communication performs by method calls into the code.
This communication could involve a process letting another process know that some event has occurred or transferring of data from one process to another. As you can see that we only use method calls for communication in monolithic architectures.

**Transaction Management in Monolithic Architectures**
Transaction management in Monolith architecture is quite easy compared to Microservice Architecture.  Many frameworks or languages contains some mechanism for transaction management. 
These mechanism have a single database of the whole application. They are developed for scenarios where all transactions are running on a single context. In other words, we can simply commit and rollback operations with these mechanism in monolith architectures.
Lets think about our e-commerce domain, We have transactional use case when placing order.
Lets see pseudo code fore place_order method
`function place_order()
 do_payment
 decrease_stock
 send_shipment
 generate_bill
 update_order`
As you can see that we can handle all operations into one method and surround operation in a transactional scope.
By this way, Transactions operated in the transaction scope are kept in memory without writing to the database until they are committed, and if a Rollback is made at any time, all transactions that have been processed so far in the scope are deleted from memory and the transaction is canceled. Without rollback, when Commit is written to the database, the transaction is completed successfully.