Between "what to build" and "writing the code" sits design: deciding how the software will be shaped — its parts, how they fit, and what to hide. This chapter covers the ideas that make software changeable: abstraction and modularity, the all-important coupling and cohesion, the big architectural styles from monoliths to microservices, how parts talk through APIs, and the named patterns teams reuse.
5 topics
You wouldn't build a house by buying wood and starting to nail. You'd draw a plan first — rooms, doorways, where the plumbing runs. Software has the same step, and skipping it doesn't remove it; it just makes the design accidental. This chapter is about doing it on purpose.
Five topics. First, what design even is — abstraction and modeling. Then the single most important pair of words for changeable software: coupling and cohesion. Then the big-picture shapes a whole system can take, from one block to many small services. Then how the parts talk to each other and remember things — APIs and data. And finally the named, reusable solutions (and the messes to avoid) that teams communicate with.
Levels of design, from the whole system down
Architecture
the big shape — one block or many services
Modules and their boundaries
how the parts are split and how loosely they connect
APIs and data
the contracts between parts, and where state lives