Conclusion: Production-Ready, Deliberately

You started with a catalogue problem. The Gang of Four named twenty-three patterns, the cloud catalogues add dozens more, and a small team that tries to learn all of them ships nothing or over-builds everything. The book's answer was never "learn more." It was "learn the right few, in order, and know what each one costs you to keep."

That few is the Pareto stack: the top patterns at each of seven altitudes, from the object up to the container. One app carried the whole climb so you could watch them line up. A food-delivery marketplace, the kind you have ordered from: a customer places an Order, a restaurant prepares it, a courier carries it. At the bottom, object patterns organise the code inside a boundary, and the Order's lifecycle is a State machine while courier selection is a CourierMatchingStrategy. Component patterns shape one service so it stays testable, and an OrderPlaced domain event fans out to the kitchen. Data patterns hold state and let it evolve, with restaurants as tenants behind a tenant_id and Row-Level Security. Messaging moves that state between services without dropping it. A flaky payment gateway becomes a non-event once the resilience patterns sit in front of it. Higher up, observability lets you see inside a running system and wake someone when an order stalls. And the hosting patterns put the whole thing on a cloud without marrying one.

The vocabulary, climbed in order

The order is the point. You don't reach for a Saga before you have a distributed transaction, and you don't reach for Event Sourcing because a blog post made it sound clever. Each altitude assumes the one below it is solid. A Circuit Breaker around an OrderGateway that nobody can reason about just wraps a problem in a second problem.

Patterns are vocabulary, not architecture. They give a team a shared language for decisions it still has to make. As Robert C. Martin argues in Clean Code, the names carry the design intent. CourierMatchingStrategy doesn't decide which courier gets the order; it names the shape so two engineers can talk about nearest-versus-fastest without drawing on a whiteboard for an hour. That is most of the value: a small team moves faster when it argues in the same words.

Patterns don't design the system. They let you describe one fast enough to change your mind cheaply.

Applied with judgement

Every pattern in Part II carried a skip-if, and that was the harder half of the book. The selection criterion ran underneath all of it: maximum production-readiness per unit of team capacity. A pattern a five-person team can't maintain is a liability the day after it merges, not an asset.

This is the over-engineering tax, and it is real money. Every pattern you adopt is one you carry forever. The honest default is boring: single-tenant before multitenancy, CRUD Order rows before an event-sourced stream, a monolith before microservices, a tenant_id and a Row-Level Security policy before a database per restaurant. You earn the heavier pattern by hitting the wall the simple one couldn't, and not a sprint sooner.

The deferring question is the whole discipline in one line. What breaks if I don't add this yet? If you can answer with a concrete failure you've actually seen, reach for the pattern. If the answer is "it might not scale someday," you've found a tax, not a requirement. A single restaurant on a single schema does not need a Saga; the day a real charge has to be refunded because a courier never showed, it does.

The code under all of it

The stances held for the whole book because they're the cheap ones to live with. SQL-first data access through a thin Data Gateway, the OrderGateway calling stored procedures behind a small interface, not a heavy ORM you can't reason about under load. Polly for the resilience pipeline wrapping the payment call. OpenTelemetry and Serilog for the things you have to see. A container as the portability boundary, state pushed outside it, the same image on GCP (AWS, Azure) without a rewrite.

var pipeline = new ResiliencePipelineBuilder()
    .AddRetry(new RetryStrategyOptions { BackoffType = DelayBackoffType.Exponential, UseJitter = true })
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions { FailureRatio = 0.5 })
    .AddTimeout(TimeSpan.FromSeconds(10))
    .Build();

None of that is exotic. It's the smallest set of choices that survives a year of production with nobody on call but you. The Order Service in Chapter 10 wired the lot together, and the surprising thing about it was how little surprised anyone. A customer places an order, the Outbox publishes OrderPlaced, the kitchen and courier workers pick it up, a payment Saga charges and pays out, and the customer reads live status from a projection. Each altitude doing one job, on the same Order you met in the first chapter.

What this leaves you with

Production-ready is a bar you clear, not a maximum you chase. The bar is finite and it is learnable. It never required a platform team standing behind you, whatever the industry likes to imply. A small team fluent in this vocabulary builds pretty much any modern, cloud-agnostic system, a food-delivery marketplace or whatever you actually ship, and then keeps it running without paging itself awake.

This is how we build internally. The foreword said the list stopped being private a while ago: it became the thing we hand a new engineer in their first week, the same Order climbing the same ladder, across the work we ship for clients and our own systems. There's a team that ships exactly this stack by default, because being fluent in the whole vocabulary is the day job. That's You-Source's Dev on Demand: a fractional engineer who has climbed every rung of this ladder before and knows which twenty per cent your system actually needs. If that's a shortcut you'd rather take than build the fluency yourself, the company is easy enough to find.

Either way, the bar is the same, and you now know where it sits.

Maintain what you ship. The right twenty per cent.