01 — Design as Decision Making¶

Driving question: How can a design decision be defended without appealing to personal taste?

Learning objectives¶

Frame design as a response to forces and anticipated changes.
Distinguish essential complexity from accidental complexity.
Record assumptions and consequences of a design decision.
Compare alternatives using quality-attribute scenarios.

Design is a hypothesis about future change¶

A design allocates responsibilities and creates dependencies. Every allocation makes some changes cheap and others expensive. Good design reasoning therefore begins with scenarios such as:

add a new payment provider;
introduce an offline mode;
audit all state-changing operations;
replace a database technology;
support a stricter security policy.

A useful decision record has at least five parts:

Context — what is already true?
Forces — what competing qualities matter?
Decision — what structure or rule will we adopt?
Consequences — what becomes easier/harder?
Evidence — tests, measurements, prototypes, prior experience, or research.

Design principles as compression¶

Principles compress experience into short heuristics. The danger is losing the conditions under which the heuristic is useful. “Program to an interface,” for example, is only useful when the interface captures a meaningful stable abstraction rather than mirroring one implementation.

Pattern cargo cult

If a design explanation contains only names—Factory, Strategy, Repository, Clean Architecture—without forces or change scenarios, the explanation is incomplete.

Design / research exercise¶

Take a 5–10 class design from an existing system. Identify three plausible future changes. For each change, mark the dependencies it crosses and propose one alternative structure. Record what the alternative improves and what it makes worse.