Big Blue Series — 02 — Cracking the Book
When I first opened Blue, The DDD book by Evans E. (2004), I was faced with a feeling of climbing a mountain. If you have Blue, you know that, inside the cover there are ovals, arrows, and phrases and I just could not get it. Part of me wanted to close the book and walk away from it, and another part of me wanted to step up to the challenge, press in, and learn. I knew for sure it was not going to be a “for dummies” quick mental upgrade.
To find out if I should continue, I turned the page. Kent Beck is the first to praise the book with the brevity that Beck often uses.
“This book belongs on the shelf of every thoughtful software developer.” ~ Kent Beck
Well now there is no returning the book, even if I don’t read it!
Then Evans dedicates it “To Mom and Dad”. Sounds like a down-to-Earth accessible author.
Then I thumb through the table of contents and the language is foreign to me at that time and I thought, “what does any of this have to do with software?!” There is all this focus on models and language and then finally I start to see software concepts and then something about supple designs and then strategic designs — but really not many code examples — what gives?
I am doing my best at this point to connect with the content and it is not working. But I can be stubborn on these types of things and I just don’t give up all that easily. I get stuff done and I wanted to get this learning accomplished. I have softened since my youth, so I am glad I had that level of persistent nature back when I started out on this book.
Then, in the Forward, Martin Fowler explains his take on Blue. This was a breath of fresh air. The first sentence in the first two paragraphs for me sum up what Blue is about.
“There are many things that make software development complex. … The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure, which gives the software developers the leverage they need.” ~ Martin Fowler
I look at that quote and think to myself, is this true? Is this what I have experienced when there is a good model vs. a poor model. The answer to that question for me is, when things are complex, this is absolutely true.
I remember inheriting a project from another developer who had inherited it from one or two others. The software was backing an online custom printing job ordering site at the time. I was the sole developer. It was a mildly complex system. I had one Product Owner/Business Analyst/Therapist as my resource, Vickie was amazing.
The software was a cut and paste job, nothing reused.
Vickie had a lot of user requirements that would not flow into the software as the original developers were constantly working on one issue through a lot of poorly crafted code. When talking with Vickie, I kept taking note of the themes that would crop up. I would ask how the system was being used, what did not work for the users, how they wanted things to work and overall, I learned about the nature of the business. The needs were becoming very clear to me. The code, was clearly not a great representation of the business model.
I decided not to ask for permission to refactor the cut and paste code, but rather just start to morph the details of the code into what I started to see as the way the business not only organizes data, but actions too. I started grouping them into logical components. In about 4–6 months, the software was starting to look like the business. I was killing it with new features and absolutely loved walking into my home office to delight the customers day after day. I pushed to prod when it was ready — hourly.
After a while, some contractors from oversees came over to take over the codebase. Vickie initially told me that they did not understand the code and complained about my work. Then I checked in on her about a year later, and she privately told me that, after they started to see how the business worked and compared that to the code, they actually were amazed at how easy it was to understand the code. It really was all because of how much I used the way the business works as the way I wrote the code.
So my initial style of development was compatible with DDD and I really never even knew it. This was a raw and crude example, but the domain model being honored is a great asset in the code for a plethora of benefits. This is not the only time I have had this experience. There are other projects that I was not afforded the opportunity to know or explore the domain model well, and well, those were painful projects.
This is why Blue became more important to me than most of the other resources on my bookshelf.
I say all of this to say, if you are a domain owner or expert, you need to really work with the team to express the model as a team. If you are a developer, you need to work with the experts to better understand the deeper domain model and to express that model in code and in tests. Doing this will provide a true acceleration of development you cannot get any other way.
If you are still interested in how to better do this, then I suggest you get Blue and follow along as we work out the details of this skill in the coming days, weeks and months. Until then…
I hope I see you in the next installment of — the Big Blue Series.
References
Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the heart of software. Addison-Wesley Professional
