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

Interactions of multiple rules or compositions of calculations become extremely
difficult to predict. The developer calling an operation must understand its
implementation and the implementation of all its delegations in order to anticipate the
result. The usefulness of any abstraction of interfaces is limited if the developers are
forced to pierce the veil. Without safely predictable abstractions, the developers must
limit the combinatory explosion, placing a low ceiling on the richness of behavior that is
feasible to build.
Operations that return results without producing side effects are called 
functions
. A function can be
called multiple times and return the same value each time. A function can call on other functions
without worrying about the depth of nesting. Functions are much easier to test than operations
that have side effects. For these reasons, functions lower risk.
Obviously, you can't avoid commands in most software systems, but the problem can be mitigated
in two ways. First, you can keep the commands and queries strictly segregated in different
operations. Ensure that the methods that cause changes do not return domain data and are kept
as simple as possible. Perform all queries and calculations in methods that cause no observable
side effects (Meyer 1988).
Second, there are often alternative models and designs that do not call for an existing object to be
modified at all. Instead, a new 
VALUE OBJECT
, representing the result of the computation, is created
and returned. This is a common technique, which will be illustrated in the example that follows. A
VALUE OBJECT
can be created in answer to a query, handed off, and forgotten—unlike an 
ENTITY
,
whose life cycle is carefully regulated.
V
ALUE OBJECTS
are immutable, which implies that, apart from initializers called only during creation,
all
their operations are functions. V
ALUE OBJECTS
, like functions, are safer to use and easier to test.
An operation that mixes logic or calculations with state change should be refactored into two
separate operations (Fowler 1999, p. 279). But by definition, this segregation of side effects into
simple command methods only applies to 
ENTITIES
. 
After
completing the refactoring to separate
modification from querying, consider a second refactoring to move the responsibility for the
complex calculations into a 
VALUE OBJECT
. The side effect often can be completely eliminated by
deriving a 
VALUE OBJECT
instead of changing existing state, or by moving the entire responsibility

---

into a 
VALUE OBJECT
.
Therefore: