In Domain-Driven Design (DDD), domain invariants are fundamental principles or rules that must always hold true within a specific domain. These invariants define constraints or conditions that govern the behavior and state of the entities, value objects, and aggregates within the domain.
They emphasize the Always-valid rule:
Your domain model should always be in a valid state.
By using invariants, your domain model guarantees that it cannot represent illegal states. These invariants define the domain class: that class is what it is because of them. Therefore, you can’t possibly violate these invariants. If you do so, the domain class would simply cease being the thing you expect it to be; it’d become something else.
As Greg Young explains it:
A unicorn without a horn is a horse, not a unicorn.
There are multiple ways to protect those invariants. Using value objects and taking advantage of the type system are a great help here. However not all invariants can be enforced by the type system.
In that situation we can use Smart Constructors which is a function to create values only if they pass a certain criteria.
Let’s look at an example…
We have a small ProductItem value object (notice that I’m using C# record types here). As we don’t want to create the value object directly, we made the constructor private.
Now we add a static method that does the necessary validation before creating the value object:
Remark: The example above could probably be handled using a normal constructor but you get the point.
Learn more
Always-Valid Domain Model · Enterprise Craftsmanship