I'm studying up on clean and as a result am quite dramatically rethinking a great deal of how I design and write software.
I've thing I'm still wrestling with however, is for business rules like "on save updates to some item, first load All the list of items I have permission to view/edit etc, confirm that this item is in the list, and that the item category is not currently locked from use, (and other rules etc etc)".. because that is a (complex but not atypical) business rule, and so should be handled in the application domain rather than push business logic into the db/persistence layer.
However it seems to me that to efficiently check these conditions it is often going to be best handled with a nicely crafted db query, rather than loading all data into the application domain...
Without prematurely optimization, what's a recommended approach or some uncle Bob articles dealing with this question? Or would he say "validate in the domain until it becomes a problem"??
I am really struggling to find any good examples / samples for anything other than the most basic of use cases.
Hi all, thanks for the replies. I should have been clearer, I've been writing (mostly web app) software for a long time, and have definitely already experienced and agree with all the topics you collectively describe (validate by backend, don't trust client data, generally speaking chase raw efficiency only when required, however acknowledge strengths of the db tools when available, etc etc) and have gone through the developer learning lifecycle of "throw it all together" to "build a giant fat controller with N-tiers applications" code trends, and now really liking and investigating the clean / single responsibility style etc, basically as the result of a few projects recently that evolved into quite clunky and widely-distributed business rules as the projects evolved and further client requirements came to light.
In particular, I'm looking at Clean style architecture in the context of building REST apis for client-facing as well as internal-usage functionality, where many of the business rules might be much more complex than basically every example you see on the net (even by the Clean / Hex architecture guys themselves).
So I guess I was really asking (and failed to state clearly) about how Clean and a REST api would sit together, where most MVC stuff you see these days has incoming request validators (e.g FluentValidation library in .NET), but where many of my "validation" rules are not so much "is this a string of less than 50 characters" but more "can this user calling this usercase/interactor perform this operation on this collection of data given that some related object is currently locked by Team X until later in the month etc etc"... those kind of deeply involved validations where LOTS of business domain objects and domain rules are applicable.
Should I spin those rules out into a specific kind of Validator-object type to accompany each usecase-interactor (inspired by the FluentValidator project but with more business logic and data access involved), should I treat the validation somewhat like a Gateway, should i put those validations IN a gateway (which i think is wrong), etc etc.
For reference, I am going off several articles like this, but Mattia doesn't discuss validation much.
But I guess the short answer to my question is much like the answer that I have accepted: "It's never easy, and it depends".