Design Modular Monolithic Architecture for E-Commerce Applications with Step by Step
In this article, we are going to learn how to design E-Commerce Applications with Modular Monolithic Architecture and Step by Step.
By this article, we are going to learn Modular Monolithic Architecture, Benefits and Challenges of Modular Monolithic Architecture and Design our E-Commerce application with Modular Monolithic Architecture.
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
Architecture Design Flow
There are many approaches and patterns that evolved over decades of software development, and all have their own benefits and challenges.
Before we design any architecture we will always start from Problem which is Business Problem that drive our design considerations. Here is the problem about Clean architecture and try to solve this problem during the article.
After that, we have learned Architecture Design Patterns and Principles about Modular Monolithic Architectures that you can check articles below:
- Microservices Killer: Modular Monolithic Architecture
- Monolith First Approach Before Moving to Microservices
So now, according to our Architecture Design flow at above, We are at Design step. But before design our system We should ask ourselves:
- What we have in our design toolbox ? What we have learned so far ?
So that means, every time when we design our architecture, We should always start with writing down FRs and NFRs. Also its good to write-down Constraints or Limitations of project, for example cost, time and so on.
Architecture Design Toolbox
Here you can see the Architecture Design Toolbox that we will use during the article when designing our E-Commerce application:
Functional Requirements — FRs
Basically we are going to design simple e-commerce application and we need to write down business cases that means write down 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
Non-Functional Requirements — N-FRs
After getting requirements, as a Software Architect, we should consider Non-Functional Requirements. Since this is the first iteration of our e-commerce application, we don’t aim to super scalability and handle millions of request. Instead we will start with small and basics that’s why I have added to
- Availability
- High number of Concurrent User
- Maintainability
- Flexibility
- Testable
- Scalability
- Reliability
- Re-usability
As you can see that we have added Scalability Reliability, Re-usability and updated High number of Concurrent User. These are benefits of Modular Monolithic Architecture that will comes our architecture.
Architecture Styles
After understanding Functional and Non-Functional requirements, now we can see our Design toolbox which includes Architectures, Patterns, Principles and Best Practices that we have learned and will apply on our project. Lets see which architecture styles that we have learned of course we have using Monolithic Architecture, Layered Architecture, Clean Architecture and Modular Monolithic Architecture in our design.
Patterns & Principles
Its good to add principles in our picture in order to remember them always. And If we expand our Patterns & Principles, we can see that
- DRY
- KISS
- YAGNI
- SoC — Separation of Concerns
- SOLID
- The Dependency Rule
- Horizontal Scaling
- Load Balancer
And also we have learned and added below principles for this chapter;
We are going to consider these principles when design our architecture. So for now we have learned only these items and load our design toolbox with these items. But with continue our course we will discover new architectures, patterns and principles.
Design: Modular Monolithic Architecture
Here you can see the final architecture design for our e-commerce application which is applying Modular Monolithic Architecture.
Now our application are growing with new features, Business teams request a lot of new feature and we need to organize better with Modular approaches. By this way we provide Encapsulate Business Logic, Reusable Codes, Easy to Refactor, Better-Organized Dependencies and Teams. You can see that We have still 1 big relational database but this time we can separate Product and Order schema and manage them independently.
Design: Modular Monolithic Architecture-Internal
If we look at the internal structure of modules, you can see that, inside of the module we can also organize by logical horizontal layers, for example some modules follows layered architecture, and Order module follows clean architecture.
But the idea is that, we encapsulate our vertical slice use cases into modules that give lots of flexibility and reliability in our architecture.
As you can see that we have design our e-commerce application as a Modular Monolithic architecture and handle all N-FR requirements. Now we can handle good amount of requests in our e-commerce application.
Evaluate: Complexity of Presentation UI Operations
We are going to evaluate our newly designed Modular Monolithic Architecture. Here you can find benefits and drawbacks:
Benefits
- Easy Development, Debug and Deploy
- Encapsulated Vertical Slices Modules
Drawbacks
If you look at the architecture, you can directly see that every UI operations are handled in our big monolithic application. With adding new features, the Complexity of Presentation UI Operations are going to be nightmare.
Our presentation UI layer is generated from server-side, so that means when Client send request to our application we have returning server-side rendering html page which creates from our Monolithic backend application. With Modular Monolithic architecture we separate modules, but UI operations are increase the complexity of presentation layer. Because every module is trying to generate their own page.
Also UI Layer has different minor requirements, for example change view of product page and every change affect to all application and requires full deployment. Additionally Business teams has UI related requirements and those are increased so much and they requesting to deploy fast for UI related tasks. These are increase the pressure of current architecture that we need to iterate and evolve architecture again.
Problem: Improved customer experience with Separated UI and Omnichannel
We are going to discover Problems of current Modular Monolithic Architecture — E-Commerce Application. So when we are in discover Problem step, we should ask ourselves
- What’s wrong with this current architecture ?
- How can we improve the current design when project goes more advanced level ?
Here you can see Problems and potential solutions of current design:
Frontend technologies are increased with SPA — single page application. So they would like to request to developer teams Improved customer experience with Separated UI and apply SPA to provide responsive pages. For that purpose, we will apply solutions:
- Separated Presentation with SPA
- Separate Frontend — Backend
- Headless Architecture
Design the Architecture — Modular Monolithic Architecture with SPA — Separated UI — Frontend Backend
Here you can see the final architecture design for our e-commerce application which is applying Modular Monolithic Architecture with SPA — Separated UI — Frontend Backend.
Now our application are growing with new features. Business teams request a lot of new feaute in the Frontend UI application and we need to organize better with applying Separated UI and Modular approaches. So The main idea of this architecture, Separating FE (Frontend) and BE (Backend) applications.
In FE applications, we provide Develop UI related tasks into different SPA Update frontend independently of the services you can see that we have 2 instance for SPA application.
In BE applications, we have Modular Monolithic Application which implements actual Business logic and expose APIs to Frontend SPA application. By this way we have Encapsulate Business Logic, Reusable Codes, Easy to Refactor, Better-Organized Dependencies and Teams.
See that We have still 1 big relational database. But this time we can separate Product and Order schema and manage them independently.
Adapt the Architecture — Modular Monolithic Architecture with SPA — Separated UI — Frontend Backend
We are going to adapt Technology Stack for our E-Commerce application for Modular Monolithic Architecture with SPA — Separated UI — Frontend Backend. We will implement possible technology choices:
As you can see that, these time we have separated FE and BE technologies. In FE we have UI related operations, In BE we have business logics and database operations. These are example technology stacks, But Of course, You can change and adapt different technology stack for your project requirements.
DEMO: Modular Monolithic Architecture Code Review — E-Commerce App
We are going to code review of e-commerce application which is implemented on Modular Monolithic Architecture with .Net ecosystem and asp.net and use SQL server for relational databases.
Here you can see 2 GitHub link at below. In the first link we go to GitHub repository page: Code review of .Net Meeting application:
- DEMO: Kamil Grzybek — Modular Monolithic with DDD
https://github.com/kgrzybek/modular-monolith-with-ddd
https://github1s.com/kgrzybek/modular-monolith-with-ddd
Please goto links and examine Readme file. With Second link you can open repository as a project folder view. This is real-world application implemented Modular Monolithic with DDD developed by Kamil Grzybek and he has also good documentation about modular monolithic that you can check.
Evaluate: Modular Monolithic Architecture with SPA
If we evaluate the current Modular Monolithic Architecture for E-Commerce Application, you can see the Benefits and Drawbacks at below :
Still BE is big monolithic, even we separate modules, the BE application
- Can’t Scale Independently, Can’t Deploy Independently.
For example, there is a big discount season and we expect million of order, we would like to only scale Order module aggressively for a few week in peek times but it requires to scale whole application even this Reporting module won’t get any request during this period. So we said that It is still Monolithic and has Scalability and Deployment Issues.
Problem: Agility of New Features, Split Agile Teams
We are going to discover Problems of current Modular Monolithic Architecture — E-Commerce Application. So when we are in discover Problem step, we should ask ourselves:
- What’s wrong with this current architecture ?
- How can we improve the current design when project goes more advanced level ?
Here you can see Problems and potential solutions of current design:
Business teams want to provide best customer experience at Black Friday sales that means it requires to handle and process millions of request in a acceptable latency with better performance.
And the solutions are:
- Microservices Architecture
Design Microservice Architecture — E-Commerce App
If we design e-commerce application with Microservice architecture, you can see the image below:
Product microservice can use NoSQL document database Shopping Cart microservice can use NoSQL key-value pair database and Order microservice can use Relational database as per microservice data storage requirements.
What’s Next ?
- Macro-services to Nano-services: Evolution of Software Architecture
- Microservices Architecture: Problems and Solutions with Pattern and Principles
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
