Writing constraints a domain expert can actually check

OCL and Business Logic
1

A thing I have come to believe strongly, offered here for argument.

The value of OCL is not that it is formal. Plenty of notations are formal. The value is that a
correctly written constraint reads back as the sentence the domain expert said in the workshop.

Compare:

-- what people write
context Loan inv: self.a->forAll(x | x.s = 2 implies x.d <= self.l)

-- what they meant
context Loan
inv: self.advances->forAll(advance |
       advance.status = Status::Approved implies
       advance.amount <= self.creditLimit)

Same expression. The second one can be read aloud to the person who owns the rule, and they can
tell you whether it is right. The first one cannot, which means it will never be checked by
anyone who knows the answer.

Concretely, three habits:

  1. Name the iterator. | advance | not | x |.
  2. Never abbreviate a domain term. creditLimit, not cl.
  3. Break the line where the sentence breaks.

None of this affects execution. All of it affects whether the rule is correct.

2

This is the argument for OCL over hand-written validation code, put better than we put it. A rule a business owner can verify is a rule that gets verified.

3

Counterpoint, mildly: on a model with 400 constraints, the verbose ones get skimmed. I would add a fourth habit — keep constraints short enough that the reader finishes them.

4

Fair, and I agree. If a constraint is too long to read aloud, that is usually a sign it is doing two jobs and should be two constraints.

5

As the domain expert in the room on most projects: yes. I have signed off on constraints I did not understand because nobody could explain them, and that is how wrong rules ship.