principle-boundary-discipline

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

Write 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 mechanically.

No. If the boundary already validated the data, redundant nil checks deep in call chains add noise and a false sense of safety. Ask whether the data is crossing a system boundary right now; if not, validation is redundant.

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 less when a component genuinely receives untrusted input from multiple independent sources, since each entry point is its own boundary needing guards. The principle still applies, but you must correctly identify every boundary first.