In software (Private), a monolith is a single-tiered application where the UI and data access code is combined into a single program. Monoliths are self-contained, independent from other applications.
Monoliths can follow modular design patterns:
- Code modularity lets developers split the source tree into a series of modules, some of which may expose interfaces allowing extension.
- Object modularity allows reusing parts of the application or deploying them independently (shared objects; dynamic link libraries) or distributing them across multiple systems (Microsoft COM+).
The term has roots in mainframe applications.
When to use it
- Quicker to develop initially, especially with a smaller team.
- Easy to continue growing an existing codebase to meet new feature requirements.
- Reduced release engineering and operational complexity.
- "Don't repeat yourself" drives reuse.
- Easier to replicate the environment, as there's just one large component.
- Large solutions/IDE projects, leading to longer build times.
- Too many people involved in decision making.
- Highly-coupled shared components make it difficult to move quickly.
- All actions have unintended consequences.
- Data storage systems like databases become rigid due to shared dependencies.
- Sets technology stack in stone, preventing adoption of better-suited tools.