Architecture

The Architecture reference groups the two halves of designing a backend system, which read best in this order:

Architecture Decisions and Migration Paths — whether and how to split a system in the first place: what a monolith, a modular monolith, and microservices actually are; the benefits and drawbacks of microservices; when a monolith is still the right call; how to isolate backend and frontend behind an API gateway or backends for frontends; how to migrate — from a legacy technology stack to a modern one, from a monolith to a modular monolith and on to microservices, and from single-tenant installed software to multi-tenant SaaS — one safe step at a time; and which path and which technologies to pick for a brand-new project, plus a downloadable cheat sheet.
Architectural Patterns — how a system that is already split into services stays consistent: domain-driven design applied to microservices — strategic design and the tactical building blocks (entities, value objects, aggregates, repositories), why distributed transactions don’t work across services, sagas, domain events and event storming, the transactional outbox, CQRS, and event sourcing, assembled into one worked example, plus a downloadable cheat sheet.

Both halves share one vocabulary — bounded contexts, business capabilities, database per service — and link into each other wherever a decision on one side has consequences on the other: every migration path that ends with "and now that transaction spans two services" hands over to the saga, outbox, and CQRS pages, and every pattern page assumes the split it builds on was made for the reasons the decisions pages lay out.