Domain-Driven Design Case Study: So We Thought We Knew Money

Posted by Jonathan Allen on Feb 22, 2007

Sections

Process & Practices,

Development

Topics

.NET ,

Change ,

Java ,

Ruby

Tags

Refactoring ,

Domain Driven Design

In a new case study published by Domain Language, Inc., Ying Hu and Sam Peng show how they solved some major problems dealing with international currency by selectively applying Domain-Driven Design to their existing application.

The first thing Hu and Peng did was create Currency and Money classes. The first wraps a string and ensures said string is actually a valid currency. The second merges a currency with the amount of that currency.

Pretty typical stuff, but what makes this study interesting is how they thread the new class into their existing code. In one example they only change the external interface, within the class they still use a string and decimal to store the values.

But wait a second, the legacy settlementAmount and settlementCurrency still exist inside Order as private members. Isn’t it better to replace them with Money too? Yes, ideally, all private members should be replaced too. They are still there because of the shortage of time: due to the massive usage of primitive types, we found it impractical to exhaustively replace every occurrence. As a compromise, we decided to refactor important interfaces first. This way, even though many of the ugly bits are still around, they are hidden within a well defined boundary.

No case study would be complete without mentioning some of the problems they ran into. The first issue they come across is feature creep within a class.

This is only the start. These value objects are now widely used in the system. But because of their prominent expressive power, developers start to put stuff in just because of convenience.  Consider the following method defined inside Rate class:

This method adds the “moneyToAdd” to the “target” and makes sure the resulting Money object is expressed in the target Money object’s Currency. Whoever put it in probably wanted to encapsulate the conversion between two Money objects, and perhaps some form of this function would have made sense there. However, adding money certainly is not Rate’s responsibility, and so this new function weakened Rate’s representation of the rate concept and at the same time subtly coupled it to a higher layer of the system that adds Money for a particular reason.

Another issue we deal with is the unclear message sent by the fact that a fair amount of
legacy primitive types still stick around side-by-side with their value object counterparts.
Instead of refactoring, some developers continue using them. They have even added
operator overloading to convert value objects back to primitive types!

Hu and Peng conclude on a positive note.

And yet, in spite of all the incompleteness and imperfection of our ongoing development work, these "domain fundamentals" have raised our level of abstraction above the level of decimals and strings, and have been one of the keys to allowing our system to continue to develop and produce rich applications. Our domain model is evolving, and so is our domain- driven design journey. 

Do you have your own stories about introducing Domain-Driven Design into an existing project? Let us know.

 

• Older >