Distributed components require coordinated changes and joint deployments.
Use this profile to understand the building block briefly, place it in the model, and open related building blocks.
Theoretical construct: explains a term, principle, or mental model.
Concrete cog in the system that works inside larger relationships.
A distributed monolith is a system of separate services whose tight coupling creates the costs of distribution without enabling independent changes and deployments.
The term emerged as a critique of microservice decompositions where boundaries and distribution do not align. The microservices discussion by Martin Fowler and James Lewis highlighted that network communication adds distribution costs and coupling.
Imagine several houses that stand apart but share corridors, elevators, and fixed routines. One service cannot change or fail freely because many others wait for it synchronously.
The concept captures a concrete system property that affects engineering decisions.
This concept shows architecture teams when service splitting merely moves dependencies and when modularization or a well-structured monolith is the better choice.
This concept shows architecture teams when service splitting merely moves dependencies and when modularization or a well-structured monolith is the better choice.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.