Monolithic architecture packages an application's major functionality into one deployable unit. Different features share a codebase, and internal functionality may lack explicit interfaces or strong module boundaries. section 1.4.2
A monolith can implement the same use cases as a distributed application, but shared code creates coordination pressure. Teams must manage overlapping changes, complex merges, feature branches, and a common continuous integration pipeline. section 1.4.2 section 1.4.1
Operational trade-offs include:
- Scale the entire application when only one functionality needs additional capacity. section 1.4.2
- Coordinate changes across teams because functionality shares one repository and may overlap internally. section 1.4.2
- Trade independently evolving services and fine-grained scaling for a simpler bundled implementation. section 1.4.2
Conference application
A monolithic Conference application would bundle the functionality behind the home page, back office, and call-for-proposals use case into one application instead of separating it into services. section 1.4.1
Figure 1.20 In a monolith application, all the logic to implement different use cases are bundled together. This push different teams to work on the same codebase and requires them to have complex coordination practices to avoid conflicting changes.
Shows how bundling multiple use cases into one application puts different teams on the same codebase and demands coordination to prevent conflicting changes. section 1.4.2
