Breakthrough

Returns from refactoring are not always linear
Each refinement of the code and model provides the developers more clarity of the problem they are solving
This clearer clarity is a potential for a breakthrough of insights
Breakthrough is an event, happens when developers gain a deep understanding of the domain
This can lead to improved solutions that better align with the requirements

Story of a Breakthrough

Project was to build software to track a facility
Facility: a commitment by a company and/or companies to lend, in commercial banking. A loan taken out by a company.

figure-8.1

This model assumes that lender shares are fixed
Facility and Loan share a bidirectional association
Loan can contain as many Loan Investment
Each Loan Investment is a part of Investment
Facility can contain as many Investment
Design became complicated after unexpected requirements showed up.
Investors don't invest the same amount, which is why Loan Adjustment was added
Loan Adjustment tracks departures from the share, a lender agreed in Facility
This was an incremental refinement to the model.
The rules of transactions became clearer but complexity was increasing
The model had issues that were hard to solve with the complex algorithm, such as rounding inconsistencies.
They suspected their difficulties was the result of a basic design problem

Found out that the Shares of Loan and Facility can be changed independently of each other
The borrower chose $50MM out of $100MM
The 3 lenders chip in with the same proportion as the Facility, and $50MM is divided among the lenders
The borrower draws additional $30MM, which makes the total loan $80MM, which is currently under the limit of $100MM
This time Company B opted out, and Company A takes the extra share
This is common, shares of Loan is not proportional to shares of Facility
Principal payments distributed proportional to shares in Loan
When the borrow pays down the Loan, the money is divided among the lenders according to the proportion of the Loan, not the Facility
When the borrower pays a fee for having the Facility available, the money is divided according to the Facilty Shares.

Investments and Loan Investments were special cases of a fundamenetal concept: shares
Abstract Model of shares
Loan model using Share Pie
Generalisation of shares into Share Pie, simplified the calculations of shares
Most issues went away because there was no constraint between the proportions of Loan Shares and Facility Shares
Share Pie of the Loan can be adjust directly with needing the Loan Adjustment
This new domain model worked well, and the developers and business experts started to understand more clearly

However, the project was behind schedule and adopting this new model would be very difficult
Difficult due to no automated tested, and exhaustion
Discussion with project manager to adopt the new model, and they agreed
It was all finished, and it went smoothly. The algorithm was a lot simpler and the Share Pie became the unifying theme of the solution.

Transitioning to a deeper model, has a higher opportunity but also higher risk than refactoring
Changing to a deeper model, is also changing how to think about the design of the solution

Don't make getting a breakthrough the priority
This will come after refactors to the code, where insights of the model emerges
Focus on knowledge crunching and cultivating ubiquitous language, this will set the stage that will give the opportunity of a breakthrough
Modest improvements will gradually deepen the model
Watch for the opportunity of a breakthrough, but don't make it a goal to achieve.

The breakthrough was not the end of the story, but instead opened up opportunities to make the design clearer.
Facilty and Loan had extra logic that could be extracted into another Entity, Transactions.
Pace of development was accelerating due to another modelling breakthrough.