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

Clearing Development Logjams with Working Prototypes
One team has to wait for working code from another in order to move forward. Both
teams have to wait for full integration to exercise their components or get feedback
from users. This kind of congestion can often be eased by a 
MODEL-DRIVEN
prototype of
a key component, even if it does not satisfy all requirements. When implementation is
decoupled from interface, then having any working implementation at all allows
flexibility for project work to go in parallel. When the time is right, the prototype can be
replaced by a more effective implementation. In the meantime, all other parts of the
system have something to interact with during development.
Having this prototype lets the application developers move at full speed, including all integrations
with external systems. The 
Packer
development team also gets feedback as domain experts
interact with the prototype and firm up their ideas, helping clarify requirements and priorities. The
Packer
team decides to take over the prototype and tweak it to test ideas.
They also keep the interface up-to-date with their latest design, forcing refactoring of the
application, and some domain objects, thereby tackling the integration problems early.
As soon as the sophisticated 
Packer
is ready, integration is a breeze because it has been written
to a well-characterized interface—the same interface and 
ASSERTIONS
that the application was
written for when interacting with the prototype.
It took specialists in optimization algorithms months to get it right. They benefited from the
feedback they could get from users interacting with the prototype. In the meantime, all other
parts of the system have something to interact with during development.
Here we have an example of a "simplest thing that could possibly work" that actually becomes
possible because of a more sophisticated model. We can have a functioning prototype of a very
complex component in a couple dozen lines of easily understood code. A less 
MODEL-DRIVEN
approach would be harder to understand, would be harder to upgrade (because the 
Packer
would
be more coupled to the rest of the design), and in this case, would likely take longer to prototype.

---

[ Team LiB ]

---

[ Team LiB ]