There is no easy answer here. Where and when validation happens requires some careful analysis.
I find it helps a lot to think carefully about (1) message validation -- is this a valid message? (2) entity validation -- is this entity in a valid state? and (3) enterprise validation -- is the business system as a whole now in a valid state? These three questions map on to what is often an ACL, domain, and domain services layer. At the end of the day there's going to be corner cases though in which case as a rule of thumb there's something to be said for doing validation at the edges and moving it in closing to the center as needed. In my experience when it's not clear where validation belongs that often means nobody really understands that validation (or that validation is even wrong and is not what the business wants -- it happens!) and so there's something to be said for keeping it out of the core domain.
Superficial validation on things like form fields still occurs up in the UI layer before a Use Case is invoked. Additional validation is likely to happen in the Use Case as well. It's a ubiquitous thing so just like in any other app it should be happening at a few different points but the stuff validated in the Use Case is going to be related to the business rules it's trying to execute.
>My approach has always been to validate anything that crosses a trust boundary.
That's a good approach unless a validation requires a db call with inner join (for example). This becomes too costly to do it 5 times (for example) just to get something written into db.
A interface to define the validation aspect. 3 separate implementations of said interface : 1 for db lookup, 1 for cache lookup and last for unit tests. 1 factory method which return the instance to use depending of context. Another temporal cache that holds the instance of said interface (after all, you can never have enough caches).
And all of a sudden, validating some single shit takes +300 lines of code (plus tests). Welcome to enterprise , clean, better designed, greatly arhitected software everyone....
Hmm, how do you define "superficial validation"? Form field facultativity (better word?) cross-field consistency, range acceptance, presence of sql escape characters ... they can all be considered superficial, but also core business rule IMHO
"presence of sql escape characters" - isn't a business rule. That's technical.
Range acceptance - could defiantly be a business rule.
Cross-field consistency - Could also be a business rule.
I implement these rules both sides. Ideally i don't want an invalid command sent off in the first place. I also don't want badly implemented UI corrupting my business data.
This way i can provide instant feedback to the user, and also protect the data in case the UI is badly implemented.
The main point of these architectures is that you can use them from many user interfaces.
Adhering to dry in all cases, is not always the best solution. As the software community has discovered over the past years. Especially in relation to microservices.
In my software there's a bit of a disconnect between the application and interactors. As there is a message queue between them.
>they can all be considered superficial, but also core business rule IMHO
Business rules does not mean what the business (bosses) dictates that the app should have.
Business rules the rules for the business domain.
Whether you should escape sql (or even use sql) is a technical/application concern, not a business rule.
A business rule would be something like "customers must get 10% discount if they bought more than 100 units" or "no employee should be allowed to have a salary bigger than their manager", etc.
Field level validation(Is this email in a valid format) checking that input is sane is done at the UI level.
Business rule validation(E.g student can't be assigned more than 10 courses) is done on the entities themselves.
You put it on both sides to get the best of both. Instant feedback to the user, and on entities as last resort protection against a badly implemented interface.
> Field level validation(Is this email in a valid format) checking that input is sane is done at the UI level.
In two places in UI: as close to the user as possible (which improves
ergonomics) and at the system's border (which prevents entering invalid data
to the system at all). While the former is somewhat optional, the latter is
absolutely necessary and cannot be left to client-side JavaScript.
I find it helps a lot to think carefully about (1) message validation -- is this a valid message? (2) entity validation -- is this entity in a valid state? and (3) enterprise validation -- is the business system as a whole now in a valid state? These three questions map on to what is often an ACL, domain, and domain services layer. At the end of the day there's going to be corner cases though in which case as a rule of thumb there's something to be said for doing validation at the edges and moving it in closing to the center as needed. In my experience when it's not clear where validation belongs that often means nobody really understands that validation (or that validation is even wrong and is not what the business wants -- it happens!) and so there's something to be said for keeping it out of the core domain.