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

When the side effects of operations are only defined implicitly by their implementation,
designs with a lot of delegation become a tangle of cause and effect. The only way to
understand a program is to trace execution through branching paths. The value of
encapsulation is lost. The necessity of tracing concrete execution defeats abstraction.
We need a way of understanding the meaning of a design element and the consequences of
executing an operation without delving into its internals. I
NTENTION-REVEALING INTERFACES
carry us
part of the way there, but informal suggestions of intentions are not always enough. The "design
by contract" school goes the next step, making "assertions" about classes and methods that the
developer guarantees will be true. This style is discussed in detail in Meyer 1988. Briefly, "post-
conditions" describe the side effects of an operation, the guaranteed outcome of calling a method.
"Preconditions" are like the fine print on the contract, the conditions that must be satisfied in order
for the post-condition guarantee to hold. Class invariants make assertions about the state of an
object at the end of any operation. Invariants can also be declared for entire 
AGGREGATES
,
rigorously defining integrity rules.
All these assertions describe state, not procedures, so they are easier to analyze. Class invariants
help characterize the meaning of a class, and simplify the client developer's job by making the
objects more predictable. If you trust the guarantee of a post-condition, you don't have to worry
about how a method works. The effects of delegations should already be incorporated into the
assertions.
Therefore:
State post-conditions of operations and invariants of classes and 
AGGREGATES
. If
ASSERTIONS
 cannot be coded directly in your programming language, write automated