Skip to content

Software Design

Systems get broken into small, independently deployable components because security fixes, capacity changes and business change all arrive faster than a single monolith can absorb them. Splitting a system does not remove that pressure; it moves it to the seams between the parts. This section covers the decisions that follow: where to draw a service boundary, how services exchange information across it, and how to structure a service so its business logic outlives the frameworks wrapped around it.

Start with Microservices for the shape of a single service, then Distributed Systems using DDD for the modelling work that decides where one service ends and the next begins — Bounded Context and Aggregates are the two rules that settle what belongs inside one service.

Hexagonal Architecture covers the internal structure of one service, CloudEvents the wire format for the events services exchange, and Cloud the conventions — twelve-factor, service brokers — that keep a service portable between execution environments.