Should Application Layer Validate DTOs or Just Rely on Domain Layer?

Honestly, forget about what OOP purists say. I've found that their advice often complicates things unnecessarily. It's better to find what works for your specific situation.

You should definitely differentiate validation across various layers. The domain layer validates data sourced from both within the application and from external inputs to ensure it's used properly. Meanwhile, the application layer should validate data coming from the domain and presentation layer to ensure it adheres to business logic. Presentation should also perform validations based on the end user inputs, optimizing for UX. Yes, it may feel like you're repeating yourself with validations, but that's essential, especially for integrating diverse systems. You might only validate an email format at the presentation layer but eventually discover issues when a different team develops a new app that interacts with the same data.

Many confuse validation and verification, but they're distinct processes. Validation happens in the service layer where you ensure that inputs match the expected types, structures, and ranges—like checking if numbers are integers or floats, or if strings are encoded correctly. On the other hand, verification occurs at the domain level, where you assess the inputs' content—like confirming that referenced database objects exist and whether input combinations are logical.

I typically handle validation only in the domain layer, with some exceptions. For instance, I'd integrate rules into the OpenAPI specification for things like length limits to keep clients informed about what's valid. Those are basically duplicative checks, but since much of the code is auto-generated, it's not a big deal. Also, there are certain technical validations related to infrastructure — like checking database constraints or specific requirements for integrations — that aren't suited for the domain layer. However, for the most part, my focus is on domain validation.