State and recovery
A statement about your data that must never be false — enforced by the system that stores it, not by the code that happens to be running.
Also called Business rule · Инвариант домена
An account balance never below zero unless an overdraft exists. A vehicle never rented to two people over the same hours. An invoice total always equal to the sum of its lines. These are not validations, they are properties of the business, and the difference is where they are enforced.
Put a rule in the application and it holds for the paths that go through that application. Then an import script runs, an admin edits a row, a second service is written by a different team, and the rule is silently no longer true — for a subset of rows nobody can identify afterwards. Put it in the database as a constraint and it holds for every writer that has ever existed and every one that will.
This practice sells that as the invariant on its architecture work: the domain model is the product. Not the interface, not the framework, not the stack — the set of statements the data is guaranteed to satisfy, because everything else is replaceable and that is not.
The rule is written once, in the service that owns the feature, and holds until the second writer appears — which is always. By the time the violation is noticed the invalid rows are months old, mixed with valid ones, and nobody can say which state was correct. Write it as a constraint where the data lives; the application then cannot be the reason it is broken.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.