Reading Note on DDD(Domain Driven Design) - Model refactoring

There is another example that is worth noting. Unlike the previous one, which is trivial (though designed very well to demonstrate a purpose), this example in chapter 8 (titled breakthrough) is a real application that the author experienced and demonstrates model refactoring takes effort and courage. 

In this example, companies make investment into a Facility, which loans money to others. The original model was like this:

This model assumes when Facility make loans, investors will make loans according to the shares of their investment. For example, if company A, company B, and company C each make investment 1 million, if the facility is to make a loan of 1 million, each company will make a loan of 333,333.

Pretty soon, developers realize it is not the case. When investors make loans, they can negotiate among themselves and make less or more loans. No problem, developers came up with this model:

In this model, a new concept “Loan Adjustment” is added, which will adjust the original shares (the shares the investors invest into the Facility). 

This is an awkward design, because:

•  Though not mentioned in the book, I am pretty sure business experts do not have a concept of “Loan Adjustment”. To them, Facility investment shares and loan shares are naturally two different things, not having the relationship of one “adjusting” the other. Using this concept ruins UBIQUITOUS LANGUAGE.
•  An awkward design makes it hard to react to business changes. Say, borrowers make a principle payment. According to this design, should the payment go through a “payment adjustment” to be paid to investors with correct shares? This will make it double awkward.

By talking to business experts, developers hit a breakthrough: facility shares and loan shares are separate, and can be changed independently. Although they are different, developers abstract them into model “SharePie”:

       

The rest of the story is more interesting than the model itself. Developers made a breakthrough in the model, however, they have been working on this project for 4 months now, to implement this new model means they had to rewrite a large part of the code and retesting a lot of things (one can image the scope of changes by comparing the two models), which will take up 3 weeks of team effort, which means zero new user stories being done in 1.5 iterations (unless you model refactoring as technical user stories, which is a tough sell to some project managers), and demoing to users the same features they’ve seen before! Fortunately, they had a courageous project manager who stood up for the team and the team pushed through the refactoring. 

The lesson is: refactoring, is not something that can always be done in small steps, model refactoring can be dramatic. In fact, my understanding is effective model refactoring is often dramatic: at first, you knowledge of the business is limited, your original model will be crude; you gain a deeper and deeper understanding of the business, with it, you realize that if you design your model in a different way, it will be much easier to deal with issues that you’ve been struggling with. What do you do then? At this point, it may not be only a technical decision, but a project management decision.