3 ms·
In business and administrative applications, there are very few reliable "invariants". Demo examples often use physics and geometry for a reason: Mother nature
by tabtab 4y ago
In business and administrative applications, there are very few reliable "invariants". Demo examples often use physics and geometry for a reason: Mother nature rarely changes those. Biz is different: new legislation, corporate edicts, new CEO's etc. can "rewrite" anything. These animal and shape demos gave too many the wrong impression of categories and types, creating "spaghetti class" messes that are still being cleaned up today.
Has-A has replaced Is-A as the better modelling mechanism in my domain, but it turns out relational does Has-A better than OOP modelling because it's based around set theory, not category hierarchies.
- anonymousDan 4y agoI don't see any problem with evolving invariants over time as business requirements change. The point is to be clear about your invariants for any given release.
- tabtab 4y agoWe usually put most "constraints" in the database. It's often a D.R.Y. violation to echo them in code.
- anonymousDan 4y agoAh, I think I understand your previous comment a bit better now. Yes it's a fair point about the best place to enforce the invariants.
- bmm6o 4y agoIf the requirements change then the code is changed and the invariants are updated as necessary.