growing-outside-in-systems

STARTER_CHARACTER = 🔴🟢 # Outside-In TDD with Hexagonal Architecture Build features by driving design from the outside in. Every feature starts with a failing acceptance test. Design emerges through disciplined Red-Green-Refactor cycles. Infrastructure is deferred until the domain API is proven. Unlike inside-out TDD with mocks, this approach tests behavior at the boundary — not implementation details — making the suite refactor-friendly by design. See [methodology.md](references/methodology.md#why-outside-in-over-regular-tdd). For canonical terms used throughout, see [references/glossary.md](references/glossary.md). --- ## The Two Loops **Outer loop (Acceptance test):** Write a failing test scoped at the service/system boundary. This test exercises integration across Bounded Contexts using in-memory adapters. It defines "done." **Inner loop (Red-Green-Refactor):** Cycles inside a Bounded Context to make the outer test pass. Drop into this loop only to implement what the acceptance test demands. Every feature starts from the outside in. The acceptance test drives the process. --- ## Test Priorities Acceptance and component tests are the primary instruments. Unit tests are the exception. - **Acceptance tests** — service/system boundary, in-process, in-memory adapters; read as specifications - **Component tests** — single Bounded Context; drives internal module design via in-memory adapters - **Unit tests** — exception only: well isolated ,genuinely complex, algor...