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

Chapter Fourteen. Maintaining Model
Integrity
I once worked on a project where several teams were working in parallel on a major new system.
One day, the team working on the customer-invoicing module was ready to implement an object
they called 
Charge
, when they discovered that another team had already built one. Diligently,
they set out to reuse the existing object. They discovered it didn't have an "expense code," so
they added one. It already had the "posted amount" attribute they needed. They had been
planning to call it "amount due," but—what's in a name?—they changed it. Adding a few more
methods and associations, they got something that looked like what they wanted, without
disturbing what was there. They had to ignore many associations they didn't need, but their
application module ran.
A few days later, mysterious problems surfaced in the bill-payment application module for which
the 
Charge
had originally been written. Strange 
Charges
appeared that no one remembered
entering and that didn't make any sense. The program began to crash when some functions were
used, particularly the month-to-date tax report. Investigation revealed that the crash resulted
when a function was used that summed up the amount deductible for all the current month's
payments. The mystery records had no value in the "percent deductible" field, although the
validation of the data-entry application required it and even put in a default value.
The problem was that these two groups had 
different models
, but they did not realize it, and there
were no processes in place to detect it. Each made assumptions about the nature of a charge that
were useful in their context (billing customers versus paying vendors). When their code was
combined without resolving these contradictions, the result was unreliable software.
If only they had been more aware of this reality, they could have consciously decided how to deal
with it. That might have meant working together to hammer out a common model and then
writing an automated test suite to prevent future surprises. Or it might simply have meant an
agreement to develop separate models and keep hands off each other's code. Either way, it starts
with an explicit agreement on the boundaries within which each model applies.
What did they do once they knew about the problem? They created separate