mirror of
https://github.com/meysamhadeli/booking-microservices.git
synced 2026-04-20 02:51:42 +08:00
30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
# 🪁 Modular Monolith Architecture Style
|
|
|
|
> In **Modular Monolith Architecture**, the application is divided into modules, each responsible for a specific functionality. However, the entire application is still deployed as a single unit.
|
|
|
|
# Table of Contents
|
|
|
|
- [Key Features](#key-features)
|
|
- [When to Use](#when-to-use)
|
|
- [Challenges](#challenges)
|
|
|
|
|
|
## Key Features
|
|
1. **Modular Design**: The application is divided into modules, each responsible for a specific functionality.
|
|
2. **Loose Coupling**: Modules interact through well-defined interfaces, improving maintainability.
|
|
3. **Single Deployment**: The entire application is still deployed as one unit.
|
|
4. **Shared Database**: Typically uses a single database, but modules can have their own schemas or tables.
|
|
|
|
|
|
## When to Use
|
|
1. **Medium to Large Projects**: Suitable for applications with growing complexity but not ready for microservices.
|
|
2. **Better Maintainability**: Ideal for teams wanting a more organized and maintainable codebase than a traditional monolith.
|
|
3. **Future-Proofing**: A stepping stone toward microservices, allowing teams to prepare for future scalability.
|
|
4. **Single Team or Small Teams**: Works well for teams that want modularity without the overhead of distributed systems.
|
|
|
|
|
|
## Challenges
|
|
- Still a single deployment unit, so scaling is limited.
|
|
- Requires careful design to avoid tight coupling between modules.
|
|
- Not as scalable or fault-tolerant as microservices.
|