Share Pie: The DDD Treasure Hidden in Plain Sight
There’s an aspect of Domain-Driven Design that rarely gets talked about. I think it’s the most important aspect of DDD, yet if you search online for “Domain-Driven Design”, you won’t find it.
This treasure has been hiding in plain sight all along. It’s the Share Pie story in chapter 8 of Eric Evans’ DDD book.
To me, this story is what DDD is really about: developing the design mindset of a modeller to drive product innovation and enable continuous delivery of value, involving frequent collaboration with domain experts.
It’s also just a great story which I never get bored of re-reading and reminds of why I love DDD.
The Share Pie Story
In Chapter 8, Breakthrough you quickly get the impression Eric is setting the scene for something epic. Any story that opens with “After a long New York winter of refactoring” is guaranteed to get DDD enthusiasts excited.
After a long New York winter of refactoring, we had arrived at a model that captured some of the key knowledge of the domain and a design that did some real work for the application. We were developing a core part of a large application for managing syndicated loans in an investment bank.
It sounds like it’s been a challenge, but nevertheless he’s showing some satisfaction at the outcome of their winter’s work. He then grabs our attention by telling us the scale of the opportunity (and a bit of name-dropping):
When Intel wants to build a billion-dollar factory, they need a loan that is too big for any single lending company to take on, so the lenders form a syndicate that pools its resources to support a facility. An investment bank usually acts as syndicate leader, coordinating transactions and other services. Our project was to build software to track and support this whole process.
We then learn exactly what he meant by the long New York winter of refactoring — fixing somebody else’s mess. But at-least now they are in a good place.
We were feeling pretty good. Four months before, we had been in deep trouble with a completely unworkable, inherited code base, which we had since wrestled into a coherent MODEL-DRIVEN DESIGN.
But then the story takes a turn. They weren’t in such a good place after all. They were in that difficult place we all find ourselves in at some point: 80/20 land. Implementing the happy paths was relatively easy, implementing all of the other requirements posed a much more intricate challenge.
But there were some disconcerting signs. We kept stumbling over unexpected requirements that complicated the design. A major example was the creeping understanding that the shares in a Facility were only a guideline…
After implementing the common use cases, they were now uncovering complexity that broke their mental models of the domain. They were able to continue adding new features by adding the Loan Adjustments concept to their model, but it seems like it was just a crutch as the codebase was getting out of control.
…We had accommodated this by adding Loan Adjustments to the model… Refinements of this kind allowed us to keep up as the rules of various transactions became clearer. But complexity was increasing, and we did not seem to be converging quickly onto really solid functionality.
Eric and his team knew that the growing complexity of the code was going to become a critical problem. More importantly, as skilled modellers, they were able to sense that their conceptual understanding of the domain was potentially flawed.
We began to suspect that our difficulties were symptomatic of a basic design problem.
The story then takes a positive turn. Eric and his team figure out the fundamental issue in their understanding and model.
Suddenly one week it dawned on us what was wrong. Our model tied together the Facility and Loan shares in a way that was not appropriate to the business.
They collaboratively design their new model at the whiteboard with domain experts, and walked through concrete scenarios to validate the model.
With the business experts nodding, enthusiastically helping… we hashed out a new model on a whiteboard… we walked through numerous scenarios using a visualization of the new model
I know that Eric is a big fan of concrete use cases in real life. He likes to prove that his models actually work in reality. In the Share Pie story, he shows us that by sharing one of the concrete examples (the below is just a small extract of the full example):
This diagram says that the borrower has chosen to draw an initial $50MM from the $100MM committed under the Facility. The three lenders chip in their shares in exact proportion to the Facility shares, resulting in a $50MM Loan divided among the lenders…
Demonstrating their modelling expertise again, Eric and his team are able to reflect on precisely why the old model didn’t work and what would be the key to producing a better one. They stumble into the domain concept of shares.
We had two deep insights. First was the realization that our “Investments” and “Loan Investments” were just two special cases of a general and fundamental concept: shares. Shares of a facility, shares of a loan, shares of a payment distribution.
This new insight does indeed translate into a positive modelling breakthrough. Their fundamental design issue has been emphatically addressed.
Suddenly, on the basis of this new way of looking at the domain, we could run through every scenario we had ever encountered relatively effortlessly, much more simply than ever before.
But then the story takes a downward turn.
Our new model worked well. Really, really well.
And we all felt sick!
We were under a severe deadline; the project was already dangerously behind schedule.
That age old software problem pays Eric and his team a visit just when they didn’t need it: there’s a project deadline. And worse, they don’t have the luxury of iterating towards the new model. An overhaul is needed.
The gospel of refactoring is that you always go in small steps, always keeping everything working. But to refactor our code to this new model would require changing a lot of supporting code, and there would be few, if any, stable stopping points in between.
Eric and his team have a meeting with their project manager. Eric explains that the refactoring adds short-term risk but reduces long-term risk. The project manager heroically becomes a good guy in the story by agreeing to protect Eric and the team.
He gave us the go-ahead and told us he would handle the heat. I’ve always had tremendous admiration for the courage and trust it took for him to make that decision.
The story continues to move back into a positive trajectory as it nears a conclusion. The brave decisions of Eric and his team are now having major business-level impacts. The share pie concept they developed has become a central product concept, even used by the marketing team with customers.
this Share Pie became the unifying theme of the whole application. Technical people and business experts used it to discuss the system. Marketing people used it to explain the features to prospective customers.
In the closing discussions of the chapter, Eric highlights another important value of model breakthroughs — they lay the foundations for more modelling breakthroughs.
Just weeks after the release of the Share Pie version of the software, we noticed another awkward aspect of the model that was complicating the design
Eric then ends the chapter by casually reminding us why the implications of this story, and DDD, matters to every software professional.
Our pace of development was accelerating at a stage where most projects are beginning to bog down in the mass and complexity of what has already been built.
Analysing the Share Pie Story
I love the Share Pie story, and I find it fascinating how many important lessons about design, modelling, and DDD we can take away from it. I hope you also enjoyed my highlights, but I would still recommend reading the whole story in the book.
Modern Product-led Organizations
The story is 20 years old but still sets the standard for good product teams today. Software engineers are not typists who translate requirements into software. Software engineers contribute to designing the products and features they are building.
Eric and his team of developers worked with their domain experts to invent the concept of a Share Pie which became an important product and marketing feature.
Domain Designers
Share Pie was a new domain concept. Eric and his team were not just modelling what already existed in the physical world. They were designing and evolving parts of the domain.
This may be one of the most misunderstood parts of DDD. DDD is about designing the domain as well as modelling existing parts of it. Innovation is inventing new ideas, new domain concepts, and new domain terminology.
Beyond the Happy Path
The 80/20 rule was clearly evident in this story. Eric and his team had built an initial model that suited all of the common use cases, but the real hard work started trying to implement all of the other use cases.
As an engineer, if a model seems simple, always remind yourself to keep looking for any hidden complexity before it blindsides you.
Step Back Before Complexity Runs Loose
As Eric’s team see the code getting increasingly more complex as they hack each new feature into the original model, they have a major decision to make: keep hacking things in or step back and try to rework the model?
This might have been the decision that prevented the codebase from becoming an unmaintainable mess for the next 10 years.
We all face these decisions when working in a codebase. If we invest in our models before complexity gets out of hand, we can keep our code healthy and easier to work with. But we need the modelling and design skills to do this.
Validate Models with Concrete Scenarios
When people say that DDD is academic and purist, I know that they haven’t been exposed to true DDD. If you ever meet Eric, you’ll quickly learn that he is all about modelling concrete scenarios rather than just working with abstract models.
In the Share Pie story, Eric’s team are at the whiteboard with domain experts mapping out concrete use cases to validate their new model. If you read the book, you’ll see that the scenario is quite detailed plugging in real numbers and sequences of events to make it as realistic as possible.
Modelling for Fun and Profit
All of the successful events in this story revolve around changes to the model that bring about business benefits either directly such as share pie, or indirectly making it faster to add new features.
While Eric certainly loves modelling and takes enjoyment from it (and suffers plenty of stress too), his pleasure comes from producing something useful to the business, not creating beautiful models he can show off to his academic friends.
Continuous Modelling
One of the themes that isn’t emphasised quite so heavily in this story is the constant nature of modelling. Don’t be ashamed if you don’t invent concepts like Share Pie in your domain every week because these breakthroughs happen much less frequently.
What enabled the big Share Pie breakthrough were the many small model refactorings the team were making on a daily basis. The cost of these small domain-related changes (like renaming, and extracting parts of code) is so little that it should be a good habit of every professional developer.
Model Meets Reality
No story about software development is complete without a dastardly deadline that puts the whole project in jeopardy and stresses everyone out (although we really shouldn’t glorify this).
In this story, the engineers and project manager decided to be bold and spend the time improving the model at the risk of missing a deadline. That must have taken a lot of courage, but it wasn’t about bragging rights for the better model, it was about de-risking the project long-term.
Sometimes we need to be bold and invest in a model even if features are delayed. On other occasions, we need to accept that our model is messy but the effort to improve it is not justified.
DDD is not an excuse to prioritise modelling over delivery, but it is an excuse to challenge the over-focus on short-term at the expense of long-term sustainability.
Tactical Patterns are Extras, Not Main Characters
There is little mention of entities, aggregates, and value objects in the Share Pie story. They are mentioned briefly to make explaining the Share Pie model clearer.
This is a good reflection on DDD itself. The tactical patterns are useful in creating and describing models, but they shouldn’t be the centre of attention. And teaching the tactical patterns without teaching the value of modelling should be something we try to avoid when teaching DDD.
Let’s Make this the Decade of Modelling
A well-designed and evolved domain model provides many benefits from product innovations, to code that is easier to understand and change. My wish is that the next decade of software development will rediscover the value of design, and the DDD community will emphasise real modelling and modelling breakthroughs a bit more.
I’ve previously written about Nurturing Design in Your Software Engineering Culture, which shares some practical tips for getting started with design in general. It’s also worth keeping an eye on Mathias Verraes’ blog for modelling-related content.
But if there’s only one thing you read on the topic of design and modelling, please make it the Share Pie story in Chapter 8 of Domain-Driven Design.
