I agree with Michael that a separation of concerns often is a Good Thing. I don't know how you know what your QA/QC coverage is without clear seperate layers rather than integrated code: this is both from underneath the code as types and from above the code as assertions.Roger's question raises the issue of whether business can abdicate responsibility for requirement details. How much should they just leave to developers? How are validity requirements captured and managed: does scattering them Willy nilly in code really help code be more maintainable?I was interested to see a Ken Sutherland video yesterday where he said that being able to put hopelessly incomplete user stories at the bottom of the priority list 'Product Backlog' and refuse to implement them was essential for Agile (Scrum): if the definition of the work item is not ready enough to start work on, not implying competeness, is a sign of something being wrong.So is a tendency to make assertions part of application code a sign of disorganization (bad 'Definition of Done'?), or missing layers, or incomplete backlog items (they are not defining the necessary tests upfront during the Sprint Planning?) Or that developers are doing ad hoc private requirements extraction on the fly?Of course, sometimes performance trumps convenience; sometimes affordable QA testing depends on piggybacking the assertions into the production code. But when architects or designers fail to include a validation later or service upfront, developers may feel they gave little choice.A variant on this thought is on my blog atRegards,RickOn 11 Apr 2017 04:47, "Michael Kay" <mike@saxonica.com> wrote:An XSLT stylesheet that exists solely for the purposes of data validation doesn't look very different from a Schematron module written to perform the same function. Both are essentially a list of rules and actions: the only difference is that the schematron version is written in a language that is slightly more specialised to the task.What's a bad idea is not using XSLT for validation, but mixing data validation and data processing in the same module.So it rather depends what you mean by "application code".Michael KaySaxonicaOn 10 Apr 2017, at 18:05, Costello, Roger L. <costello@mitre.org> wrote:Hi Folks,
Lately, to my surprise, I have been hearing more and more people advocate the use of application code to enforce data constraints (data rules). Particularly the complex data rules you might expect to find in Schematron. Their argument, presumably, is that for most domain experts and business people, data rules such as the following are gibberish:
<sch:pattern id="Knowledge-about-radio-stat
ions" >
<sch:rule context="GeographicArea">
<sch:let name="stations" value="RadioStation"/>
<sch:assert test="
every $s1 in $stations, $s2 in $stations satisfies
if (pred:Disjoint($s1, $s2)) then
number($s1/band) ne number($s2/band)
else true()
">
Radio stations broadcast on different frequency bands (within an area).
</sch:assert>
</sch:rule>
</sch:pattern>
Since they are gibberish, you might as well have the developers implement the rules in application code. Out of sight, out of mind.
I guess that’s their argument.
I thought the world had moved beyond such thinking, years ago. I thought that everyone had come to the agreement that burying data rules in application code is a bad idea.
So what happened?
Did the world suddenly get amnesia? Did the experience from the last 20 years reveal that expressing data rules in text, declaratively didn’t work out as desired?
/Roger