principle-boundary-discipline

Place validation at system boundaries where untrusted data enters: CLI arguments, config files, network requests, and external APIs. Once data is parsed into typed domain objects, internal code should trust the types and skip redundant checks.

Extract business logic into pure functions with no framework dependencies, such as parse functions transforming raw bytes to typed state or scoring functions mapping state to results. The framework shell then just calls these functions, so tests need no framework setup.

No. If the boundary already validated and typed the data, redundant nil checks or re-validation inside the system add noise and a false sense of safety. Trust the types once data has crossed the boundary.

Expose domain concepts, not the boundary's private representation. Do not re-export transport, storage, framework, or wire types through the public surface; keep general-purpose mechanism inside and special-purpose policy at the edge.

It is less relevant for small scripts with no real boundaries or prototypes where a single layer handles everything. The pattern pays off when a system has clear entry points and internal logic worth testing independently.