Pattern ◆◆◆◆◇ BE.001
Hexagonal Architecture
Isolate application core logic from external dependencies using ports and adapters.
Open detail chart → Domain chart · ii
Backend
the Backend Expanse
Clean architecture, CQRS, hexagonal patterns, and API design principles for maintainable server-side systems.
Celestial position
Featured visualisation — ports & adapters
Hexagonal Boundary
Domain logic sits at the centre, insulated from the outside world. Ports define the contracts; adapters satisfy them. Infrastructure depends inward — the core depends on nothing.
domain core — business logic & entities
ports — technology-agnostic contracts
adapters — infrastructure implementations
Featured visualisation — cqrs command & query separation
Command / Query Split
Commands mutate state through a handler into the write store, then a projection syncs a denormalized read model. Queries bypass the domain model entirely — reading directly from the read store. Each path is optimized independently.
command path — write & mutate
query path — read & project
projection sync — write→read propagation
Featured visualisation — dependency injection & ioc container
IoC Container Resolution
The IoC container holds the wiring graph. At construction time it resolves each dependency, injects it into the service, and confirms the handshake. Services declare what they need — the container decides how to satisfy it, decoupling callers from implementations.
container → service · resolution token
service → dependency · injection call
ring pulse · wiring confirmed
Featured visualisation — strategy pattern & runtime delegation
Runtime Strategy Selection
OrderService invokes Checkout with a request. The context delegates to whichever ShippingStrategy is currently injected — Standard, Express, Overnight, or Economy — then returns the result. The strategy rotates every few seconds, showing how behaviour changes without modifying the calling code.
request token — client → context
standard / economy strategy active
express strategy active
overnight strategy active
Featured visualisation — event-driven architecture & pub/sub topology
Event Bus Topology
Producers emit domain events onto a shared bus; subscribers receive only the events they declare interest in. OrderSvc, InventorySvc, and PaymentSvc publish independently — the bus routes to AuditSvc (all), WarehouseSvc (orders + stock), NotifySvc (orders), and BillingSvc (payments). No producer knows its consumers.
order.placed · OrderSvc → NotifySvc, WarehouseSvc, AuditSvc
stock.updated · InventorySvc → WarehouseSvc, AuditSvc
payment.done · PaymentSvc → BillingSvc, AuditSvc
event bus · pub/sub routing layer
Skill progression — Backend Architecture
Architecture Proficiency
Foundational principles compose into advanced patterns. Select any node to inspect the skill and its role in the broader architecture.
Skill progression5 / 6
Select a skill to inspect
Pattern catalogue — Backend
Pattern ◆◆◇◇◇ BE.002
Dependency Injection
Provide dependencies to a component from the outside rather than constructing them internally.
Open detail chart → Pattern ◆◆◇◇◇ BE.003
Strategy Pattern
Define a family of algorithms behind a common interface and make them interchangeable at runtime.
Open detail chart → Pattern ◆◆◆◆◇ BE.004
CQRS
Separate read and write models to optimise each path independently and reduce contention.
Open detail chart → Principle ◆◇◇◇◇ BE.005
Single Responsibility
Every module, class, or function should have one reason to change — separating concerns produces systems that are easier to reason about.
Open detail chart →