Design principles of Monolithic Architecture — KISS, YAGNI, DRY

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

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.

Evolve Reference Monolithic Architectures**

And the last one shows how to evolve monolithic architecture.

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;

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.

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.