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

Use a well-documented shared language that can express the necessary domain information as
a common medium of communication, translating as necessary into and out of that language.
The language doesn't have to be created from scratch. Many years ago, I was contracted by a company
that had a software product written in Smalltalk that used DB2 to store its data. The company wanted the
flexibility to distribute the software to users without a DB2 license and contracted me to build an interface
to Btrieve, a lighter-weight database engine that had a free runtime distribution license. Btrieve is not fully
relational, but my client was using only a small part of DB2's power and was within the lowest common
denominator of the two databases. The company's developers had built on top of DB2 some abstractions
that were in terms of the storage of objects. I decided to use this work as the interface for my Btrieve
component.

---

This approach did work. The software smoothly integrated with my client's system. However, the lack of a
formal specification or documentation of the abstractions of persistent objects in the client's design meant
a lot of work for me to figure out the requirements of the new component. Also, there wasn't much
opportunity to reuse the component to migrate some other application from DB2 to Btrieve. And the new
software more deeply entrenched the company's model of persistence, so that refactoring that model of
persistent objects would have been even more difficult.
A better way might have been to identify the subset of the DB2 interface that the company was using and
then support that. The interface of DB2 is made up of SQL and a number of proprietary protocols.
Although it is very complex, the interface is tightly specified and thoroughly documented. The complexity
would have been mitigated because only a small subset of the interface was being used. If a component
had been developed that emulated the necessary subset of the DB2 interface, it could have been very
effectively documented for developers simply by identifying the subset. The application it was integrated
into already knew how to talk to DB2, so little additional work would have been needed. Future redesign of
the persistence layer would have been constrained only to the use of the DB2 subset, just as before the
enhancement.
The DB2 interface is an example of a 
PUBLISHED LANGUAGE
. In this case, the two models are not in the
business domain, but all the principles apply just the same. Because one of the models in the collaboration
is already a 
PUBLISHED LANGUAGE
, there is no need to introduce a third language.