principle-boundary-discipline

Place validation at system boundaries where external data enters: CLI arguments, config files, network responses, and external APIs. 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, making them testable in isolation.

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

Boundary discipline fits systems with clear edges like CLIs, services, and adapters. It is less relevant for throwaway scripts or prototypes where strict layering adds overhead without payoff, and it does not replace domain-level invariant checks.

Re-exporting transport, storage, or wire types couples consumers to the boundary's private representation. Expose domain concepts across the boundary instead, keeping general-purpose mechanism inside and special-purpose policy at the edge.