1 Step 1 — What patterns really solve (and when they don’t) Learn how to spot recurring design forces and choose patterns as trade-offs, not rules. ExercisePick one “pain” in your codebase (test brittleness, coupling, slow change) and write the force + symptom in one sentence.
2 Step 2 — Boundaries first: modules, seams, and dependency direction Learn how to design boundaries that keep change localized and make refactoring safe. ExerciseDraw a 6-box “module map” of your system and mark the highest-churn box—then propose one new seam.
3 Step 3 — Strategy: swapping behavior without conditionals everywhere Learn how Strategy reduces branching logic and improves testability of business rules. ExerciseFind one “if/else ladder” and refactor it into 2–3 strategies with a tiny factory (even in a spike branch).
4 Step 4 — Observer/Eventing: decouple workflows and side-effects Learn when events simplify workflows—and when they just hide complexity. ExerciseList one synchronous “do A then B then C” chain; identify one side-effect that can become an event subscriber.
5 Step 5 — Adapter & Facade: integrate messy dependencies cleanly Learn how to isolate vendor APIs and legacy code so your domain stays stable. ExerciseWrap one external dependency behind an interface and write one contract test that pins the behavior you rely on.
6 Step 6 — Builder/Factory: make construction explicit and test-friendly Learn how to tame complex object creation and reduce fragile test setup. ExerciseReplace one “god constructor” call in tests with a builder that has 3–5 readable defaults and one override.
7 Step 7 — Team playbook: how to decide (and review) patterns consistently Learn lightweight decision rules for reviews so patterns improve flow instead of creating debates. ExerciseAdd one “Pattern Decision Record” template to your repo with 5 bullets: context, forces, decision, consequences, tests.