06-dto-and-validation

Create separate create and update DTOs to enforce different validation rules for each operation. This approach provides deterministic, per-field validation errors at the boundary while keeping validation layered across DTO, service, and data store.

Separate create and update DTOs enforce different validation rules for each operation. This allows you to require specific fields on creation while making them optional on update, returning deterministic 400 errors with per-field details for invalid input.

Wire controller-level validation to your allowlisted DTOs to return deterministic 400 errors with per-field details. This keeps validation layered across the DTO, service, and data store, improving API reliability by rejecting invalid input at the boundary.

A DTO is specifically designed to carry data across layers and enforce input validation, not to represent a domain model or persistence entity. It focuses on allowlisting fields, validating types and formats, and enforcing safe input before data touches business logic.

Input validation is a security boundary, not optional polish, and should be enforced before data touches business logic. Define allowlisted DTOs that declare accepted fields and exclude sensitive ones to provide deterministic, per-field validation errors at the boundary.