principle-boundary-discipline

Place validation at system boundaries where external data enters: CLI arguments, config files, network requests, and external API responses. Once data crosses the boundary as typed domain objects, trust it and avoid re-validating deeper in the call chain.

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. If the boundary already validated and parsed the data into typed domain objects, redundant nil checks and re-validation inside the system add noise and a false sense of safety. Trust the types after the boundary.

Avoid it when data genuinely crosses a trust boundary mid-flow, such as calling an external service from deep inside the system. In those cases the call site becomes a new boundary and deserves its own defensive validation and error handling.

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