SOA Design Patterns is a large catalogue of patterns for designing service-oriented systems, organised from the scale of a whole enterprise down to individual service capabilities. It's part of Thomas Erl's series on service-oriented architecture, and it was developed with input from a wide community of practitioners.
Three levels of design
The book organises its patterns by scope:
- Service inventory patterns cover how a collection of services is planned and governed: standardised contracts, canonical schemas, domain inventories and shared infrastructure.
- Service design patterns cover individual services: separating capabilities, decoupling contracts from implementation, handling state and exposing legacy systems.
- Service composition patterns cover how services work together: orchestration, messaging, brokering, and keeping compositions reliable.
Ideas that outlived SOA
The vocabulary of SOA has gone out of fashion, but many of its patterns are exactly what microservice teams rediscover. Contract-first design, the service façade, legacy wrappers, the idea of an inventory with agreed standards, and the trade-offs between orchestration and choreography are all here, worked through carefully.
A service contract is a promise. Design it first, standardise it, and keep the implementation behind it free to change.
How to use it
Like most pattern catalogues, it's a reference, not a novel. The introductory chapters on design principles and the notation are worth reading in full. After that, dip into the patterns that match the problem in front of you.
Key ideas
Design the contract first.
A standardised, technology-neutral contract lets the implementation change without breaking consumers.
Think in inventories.
Services are most valuable as a planned, governed collection with shared standards, not as isolated projects.
Wrap legacy systems.
A service façade or legacy wrapper lets old systems take part in a modern architecture without exposing their internals.
Choose composition deliberately.
Orchestration and choreography each have costs. Pick the one that fits the process, not the trend.
My take
The reference I learned service design from, and a reminder that microservices didn't start from zero.
Thomas Erl's books take up a whole shelf in my study, and this is the one I've opened most often. I worked through SOA projects in the 2000s, and when microservices arrived, it was striking how many of the same lessons applied.
It's dense and very much a reference, but for architects designing service landscapes it's still one of the most complete treatments available.
Who should read it
- Architects designing service or microservice landscapes.
- Teams modernising legacy systems behind service interfaces.
- Engineers preparing for enterprise or solution architecture roles.