Lesson 13 · Senior v2 architecture
Composition roots and wiring at the edge
Where concrete dependencies belong, why the wiring code matters, and how to explain the difference between a clean edge and a leaked core.
Your win: explain what a composition root is, why v2 modules want concrete wiring at the edge, and how to review whether a module really preserves that boundary.
The problem: somebody has to build the real objects
Ports and adapters sound clean until you ask a practical question: who actually constructs the postgres repo, the handler, and the controller? The answer is the composition root. If you put that wiring in the wrong place, the dependency arrow starts bending back into the core.
What good wiring looks like here
In spike, controller constructors inject concrete repos and handlers. In eureka, `cmd/server/eureka/gserver.go` wires repos into usecases and registers the transport at the outer edge. That is the healthy pattern: the module logic stays focused on behavior, while the outer bootstrapping code owns assembly.
Cockburn + repo wiring docs
Read Cockburn's original framing, then compare it with the repo's real wiring conventions in the loaded CLAUDE/rules files.
→ Hexagonal Architecture
→ internal/eureka/CLAUDE.md · internal/spike/CLAUDE.md
Check yourself (from memory)
Q1. The composition root should usually live…
Sources. Cockburn; repo CLAUDE docs.