Loading content
Microservices are an architectural style where applications are composed of a collection of small, autonomous services that communicate over APIs. Each service is responsible for a specific function and can be developed, deployed, and scaled independently.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Microservices are small, business-focused services that can be developed, operated, and released independently.
Microservices arose in software architecture as a response to centrally released applications that were difficult to change and to the growing size of autonomous development teams. The movement took shape in 2010s practice and discussion; Martin Fowler's writing and pattern collections such as microservices.io helped establish its shared vocabulary.
Think of each service as its own workshop with a clear handoff. Workshops work independently but must agree on stable interfaces and failure behavior when they exchange work.
It defines the business responsibility and data owned by a service.
A service can change and ship independently within its contracts.
Microservices can decouple teams and changes, while introducing distributed data, network failures, observability, and operational overhead.
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.
These sources establish the term and its professional meaning.
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.