Defensive Coding

Validation lives in two places in Clean Architecture: **Domain Validation** (Rules of the Entity) and **Application Validation** (Rules of the Use Case).

1. FluentValidation

The industry standard for .NET. It allows you to define complex validation rules in a separate class (e.g., CreateUserCommandValidator). This keeps your command DTOs as clean data-containers and puts the 'Input Validation' logic in its own testable unit.

2. Fail Fast with MediatR

We use a **Validation Pipeline Behavior** in MediatR. Before our handler is even called, the behavior automatically checks all registered validators. If the input is invalid, it throws a ValidationException and stops the request. Your handler can then assume that the data it receives is clean and valid.

3. Architect Insight

Q: "Should I check if a User exists in a Validator?"

Architect Answer: "NO. Data-existence checks (like 'Is this email taken?') require database calls and belong in the **Handler** or a **Domain Service**. Validators should only check 'Format' and 'Structure' (e.g., 'Is the email format correct?', 'Is the age > 18?'). Keep your validators fast and side-effect free."