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

Container
object, 
isSafelyPacked(),
will confirm that 
Container
has all the
features specified by the 
Chemicals
it contains:
boolean isSafelyPacked(){
Iterator it = contents.iterator();
while (it.hasNext()) {
Drum drum = (Drum) it.next();
if (!drum.containerSpecification().isSatisfiedBy(this))
return false;
}
return true;
}
At this point, we could write a monitoring application that would take the inventory database and
report any unsafe situations.
Iterator it = containers.iterator();
while (it.hasNext()) {
Container container = (Container) it.next();
if (!container.isSafelyPacked())
unsafeContainers.add(container);
}
This is not the software we've been asked to write. It would be good to let the business people
know about the opportunity, but we have been charged with designing a packer. What we have is
a test for a packer. This understanding of the domain and our 
SPECIFICATION
-based model put us in
a position to define a clear and simple interface for a 
SERVICE
that will take collections of 
Drums
and 
Containers 
and pack them in compliance with the rules.
public interface WarehousePacker {
public void pack(Collection containersToFill,
Collection drumsToPack) throws NoAnswerFoundException;
/* ASSERTION: At end of pack(), the ContainerSpecification
of each Drum shall be satisfied by its Container.
If no complete solution can be found, an exception shall
be thrown. */
}
Now the task of designing an optimized constraint solver to fulfill the responsibilities of the 
Packer
service has been decoupled from the rest of the application, and those mechanisms will not clutter
the part of the design that expresses the model. (See "Declarative Style of Design," Chapter 10,
and 
COHESIVE MECHANISM
, Chapter 15.) Yet the rules 
governing
packing have not been pulled out of
the domain objects.

---