principle-boundary-discipline

Validate all inputs at the boundary where they enter the system, such as argument parsing and config file loading. Once data crosses the boundary as typed domain objects, internal code should trust the types and propagate errors without re-validation.

Error handling belongs at system boundaries like network calls, config parsing, and external API adapters. Inside the system, use typed error propagation rather than defensive checks, since the boundary already guaranteed valid data.

No. Business logic should live in pure functions with no framework dependencies so it can be tested without the framework. The framework shell stays thin and mechanical, just calling pure transforms.

Redundant nil checks deep in call chains add noise and create a false sense of safety when the boundary already validated the data. If data is not crossing a system boundary, additional validation is redundant and should be removed.

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.