11–20 of 141 posts
At what point should basic validation be completed?
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.
At what point should basic validation be completed?
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.
Earlier quoted context omitted.
My approach has always been to validate anything that crosses a trust boundary. This might be user->app; client->gateway; or app->database.
>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.
I've seen this a few times before, and it led me to believe that I was stupid. Comments like "...business rules simply don’t know anything at all about the outside world" left me wondering what components that DO know something about the outside world, actually know about the outside world? Turns out that the answer is a data access component might know where to find a database, and a client app might know where to f…
Messages might be linear but scopes are encompassing inner scopes. Encapsulation is not usually depicted as a stack.
>And finally, the ambiguous language. Why should I care that there are enterprise business rules, and application business rules? They're both rules.
Obviously because different scopes apply to the former than to the latter. TFA even clarifies that: "The key is that they ("enterprise business rules") contain rules that are not application specific - so basically any global or shareable logic that could be reused in other applications should be encapsulated in an entity".
In general, the similarities ("they're both rules") between two things don't say much (if anything at all) without considering the differences. Shiitake and Amanita Muscaria are "just mushrooms", but one can kill you.
Earlier quoted context omitted.
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.
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
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.
Surprising this has been written in 2017. It looks like java written a decade ago. This can be a kind of organizational solution much like microservices to separate concerns. This is important when collaborating with a large amount of people. Clear boundaries and all that. You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with Ab…
Because good architecture has somehow evolved?
>This can be a kind of organizational solution much like microservices to separate concerns.
This is orthogonal to microservices. And microservices aint but one model of creating applications, not "THE 2017 model".
Scott Wlaschin has recently released an [ebook]https://pragprog.com/book/swdddf/domain-modeling-made-functi... on the topic which goes into more detail.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
>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.
It remains a good approach, even in your scenario - because that perf problem is solved using a temporal cache.