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

Customer/Supplier Development Teams
Often one subsystem essentially feeds another; the "downstream" component performs analysis or
other functions that feed back very little into the "upstream" component, and all dependencies go
one way. The two subsystems commonly serve very different user communities, who do different
jobs, where different models may be useful. The tool set may also be different, so that program
code cannot be shared.
Upstream and downstream subsystems separate naturally into two 
BOUNDED CONTEXTS
. This is
especially true when the two components require different skills or employ a different tool set for
implementation. Translation is easier for having to operate in one direction only. But problems can
emerge, depending on the political relationship of the two teams.
The freewheeling development of the upstream team can be cramped if the
downstream team has veto power over changes, or if procedures for requesting
changes are too cumbersome. The up-stream team may even be inhibited, worried
about breaking the downstream system. Meanwhile, the downstream team can be
helpless, at the mercy of upstream priorities.
Downstream needs things from upstream, but upstream is not responsible for downstream
deliverables. It takes a lot of extra effort to anticipate what will affect the other team, and human
nature being what it is, and time pressures being what they are, well . . . . It makes everyone's life
easier to formalize the relationship between the teams. The process can be organized to balance
the needs of the two user communities and schedule work on features needed downstream.
On an Extreme Programming project, there already is a mechanism in place for doing just that:
the iteration planning process. All we have to do is define the relationship between the two teams
in terms of the planning process. Representatives of the downstream team can function much like
the user representatives, joining them in planning sessions, discussing directly with their fellow
"customers" the trade-offs for the tasks they want. The result is an iteration plan for the supplier
team that includes tasks the downstream team needs most or defers tasks by agreement, so there
is no expectation of delivery.

---

If a process other than XP is used, whatever analogous method serves to balance the concerns of
different users can be expanded to include the downstream application's needs.
Therefore: