# C# Architecture and APIs

Apply these rules when designing public APIs, service boundaries, or application architecture.

* Give APIs explicit, strongly typed contracts. Validate external input at the boundary and keep trusted internal paths free of redundant checks.
* Separate request models from persistence and domain models. Bind only fields the caller may set, and project only fields the caller may read.
* Authenticate and authorize before accessing protected resources. Enforce resource ownership and tenant scope in the data access path, not only in the UI or route layer.
* Bound page size, payload size, query complexity, and operation cost. Use explicit pagination for potentially large collections.
* Keep application, domain, and infrastructure concerns separate. Avoid cross-layer coupling and service-locator patterns.
* Use dependency injection when substitution or lifecycle management is needed. Keep dependencies explicit and avoid excessive constructor dependencies.
* Prefer composition over inheritance; use inheritance only when the contract requires it. Seal types when extension is not intended.
* Keep classes and methods focused. Avoid wrappers, abstractions, reflection, and global mutable state without a concrete need.
* Preserve established project and public API conventions unless a concrete compatibility or correctness issue requires a change.
* Keep authorization decisions close to the protected operation and fail closed when identity, ownership, or policy evaluation is unavailable.
* Avoid returning persistence entities, internal exception details, or fields that are not part of the public contract.