principle-boundary-discipline

Place validation at system boundaries where data enters: CLI arguments, config files, network protocols, and external APIs. Once data crosses the boundary as typed domain values, internal code should trust the types and skip re-validation.

Implement business logic as 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, keeping the shell thin and mechanical.

No. Redundant nil checks and repeated validation deep in call chains add noise and a false sense of safety. If the boundary already parsed raw data into domain types, internal code should propagate errors and trust the types.

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 fits systems with clear edges like CLIs, services, and adapters. It adds little value in small scripts with no real boundary, or where a framework already enforces validation contracts that cannot be separated from the wiring.