Microservice Pattern Language
The microservice pattern language collects architecture-practice patterns that allocate semantic responsibility and authority to independently evolvable services, connect them in service models through provided and required interfaces, govern their conversations with interaction protocols, state their operational guarantees, and select realization mechanisms. It covers decomposition, collaboration, data ownership, transactional messaging, communication, deployment, discovery, reliability, security, observability, testing, and migration.
Cohesive Correspondence
| Pattern family | Cohesive correspondence |
|---|---|
| Monolith or microservice architecture | modular-monolith and microservice-architecture practices over semantic, ownership, deployment, and failure boundaries |
| Decomposition by business capability or subdomain | DDD, service models, entity models, process graphs, authority, and team ownership |
| Service collaboration | interfaces, interaction protocols, interaction, business transactions, sagas, CQRS, API composition, and domain-event publication |
| Transactional messaging | transactional outbox, transactional inbox, log tailing, polling publication, idempotency, and commit boundaries |
| Communication and external API | EIP, request/reply, messaging, gateways, multiplexing and demultiplexing, discovery, contracts, and compatibility and evolution |
| Reliability and observability | Circuit breaking, retry, health checks, metrics, audit, tracing, and provenance |
| Deployment and infrastructure | Hosts, containers, serverless platforms, service meshes, sidecars, configuration, and service registries as realization substrate |
Microservice patterns connect DDD's semantic boundary and ownership concerns with EIP's message, channel, routing, and endpoint structures, then add operational and realization concerns such as consistency, deployment, discovery, failure isolation, and observability. These correspondences are not equivalences: a service is not automatically one bounded context, subdomain, aggregate, entity, process, observer, team, or deployment instance. Database per Service establishes an access and ownership arrangement; it does not by itself establish semantic authority or a sound service boundary. Likewise, a message labeled a domain event is not necessarily the domain occurrence itself; its meaning remains relative to the producing and consuming boundaries and their observers.
Overlapping Catalogs
Saga, CQRS, Event Sourcing, Transactional Outbox, Idempotent Consumer, Messaging, Shared Database, API Gateway, and Anti-Corruption Layer overlap DDD, EIP, enterprise application patterns, cloud patterns, and distributed-systems patterns. Cohesive preserves the source provenance while mapping them onto shared concepts rather than duplicating primitives.
Formal relations
documents: Microservice Architecture — Organizes recurring decisions, alternatives, and realization techniques associated with the architecture practice without identifying the catalog with the practice itself.
External References
- Chris Richardson, A Pattern Language for Microservices.
- Chris Richardson, Microservices Patterns, Manning, 2018.
- Microsoft, Design patterns for microservices, Azure Architecture Center.
Related concepts: pattern languages and correspondence, service, service models, interfaces, interaction protocols, multiplexing and demultiplexing, microservice architecture, modular monolith, domain-driven design, enterprise integration patterns, boundaries, interaction, sagas, CQRS, transactional outbox, transactional inbox, compatibility and evolution, observability and provenance, realization.