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

Establish a clear customer/supplier relationship between the two teams. In planning
sessions, make the downstream team play the customer role to the upstream team.
Negotiate and budget tasks for downstream requirements so that everyone
understands the commitment and schedule.
Jointly develop automated acceptance tests that will validate the interface expected.
Add these tests to the upstream team's test suite, to be run as part of its continuous
integration. This testing will free the upstream team to make changes without fear of
side effects downstream.
During the iteration, the downstream team members need to be available to the upstream
developers just as conventional customers are, to answer questions and help resolve problems.
Automating the acceptance tests is a vital part of this customer relationship. Even on the most
cooperative project, although the customer can identify and communicate its dependencies, and
the supplier can diligently try to communicate changes, without tests, surprises will happen. They
will disrupt the downstream team's work and force the upstream team to take on unscheduled,
emergency fixes. Instead, have the customer team, in collaboration with the supplier team,
develop automated acceptance tests that will validate the interface it expects. The upstream team
will run these tests as part of its standard test suite. Any change to these tests calls for
communication with the other team, because changing the tests implies changing the interface.
Customer/supplier relationships also emerge between projects in separate companies, in situations
where a single customer is very important to the business of the supplier. The tail can wag the
dog: an influential customer can make demands that are important to the up-stream project's
success, but those demands can also be disruptive to the upstream project's development. Both
parties benefit from the formalization of the process of responding to requirements, because the
cost/benefit trade-offs are even harder to see in external relationships than they are in the internal
IT situation.
There are two crucial elements to this pattern.
The relationship must be that of customer and supplier, with the implication that the
customer's needs are paramount. Because the downstream team is not the only customer,
the different customers' demands have to be balanced in negotiation—but they remain
priorities. This situation is in contrast to the poor-cousin relationship that often emerges, in
which the downstream team has to come begging to the upstream team for its needs.
1.
There must be an automated test suite that allows the upstream team to change its code
without fear of breaking the downstream, and lets the downstream team concentrate on its
own work without constantly monitoring the upstream team.
2.
In a relay race, the forward runner can't be looking backward all the time, checking. He or she has
to be able to trust the baton carrier to make the handoff precisely, or else the team will be
hopelessly slowed down.