Domain-Driven Design: Tackling Complexity in the Heart of Software

Figure 9.10.
A simple invariant like this can be enforced using case logic in each operation capable of changing
contents.
class Bucket {
private float capacity;
private float contents;
public void pourIn(float addedVolume) {
if (contents + addedVolume > capacity) {
contents = capacity;
} else {
contents = contents + addedVolume;

---

}
}
}
This logic is so simple that the rule is obvious. But you can easily imagine this constraint getting
lost in a more complicated class. Let's factor it into a separate method, with a name that clearly
and explicitly expresses the significance of the constraint.
class Bucket {
private float capacity;
private float contents;
public void pourIn(float addedVolume) {
float volumePresent = contents + addedVolume;
contents = constrainedToCapacity(volumePresent);
}
private float constrainedToCapacity(float volumePlacedIn) {
if (volumePlacedIn > capacity) return capacity;
return volumePlacedIn;
}
}
Both versions of this code enforce the constraint, but the second has a more obvious relationship
to the model (the basic requirement of 
MODEL-DRIVEN DESIGN
). This very simple rule was
understandable in its original form, but when the rules being enforced are more complex, they
start to overwhelm the object or operation they apply to, as any implicit concept does. Factoring
the constraint into its own method allows us to give it an intention-revealing name that makes the
constraint explicit in our design. It is now a named thing we can discuss. This approach also gives
the constraint room. A more complex rule than this might easily produce a method longer than its
caller (the 
pourIn()
method, in this case). This way, the caller stays simple and focused on its
task while the constraint can grow in complexity if need be.
This separate method gives the constraint some room to grow, but there are lots of cases when a
constraint just can't fit comfortably in a single method. Or even if the method stays simple, it may
call on information that the object doesn't need for its primary responsibility. The rule may just
have no good home in an existing object.
Here are some warning signs that a constraint is distorting the design of its host object.
Evaluating a constraint requires data that does not otherwise fit the object's definition.