Big Blue Series — 01 — Approaching Domain-Driven Design
Got your coffee? If so, maybe you can consume this article faster than that cup!
This kicks off the Big Blue Series — a deep dive in to a deep book.
The book is affectionately called “The Blue Book”. The published title is “Domain-Driven Design: Tackling Complexity in the Heart of Software” (Evans, 2004).
Eric Evans coined the term, wrote the book and started a new energy and great confusion in the IT industry.
It has been purchased by a lot of software professionals. I have seen it on the shelves at work in many cubicles, when few of us worked remotely. Based on my face to face conversations it has been pulled from the shopping bag, thumbed through, and then placed on the bookshelf for a time when there was time to read it. Many never found the time. A majority of the book owners I meet are in this camp. I do know of a few people that got it and ran on first read, but that is rare.
The concept is referred to as “DDD”.
This already throws people off. It is ok. Hang with me as we work together to understand what is going on with this thing called DDD as I understand it from my relationship with “Blue” as I will refer to it from this point forward.
So before we dig into Blue, I want to address you, the reader, first. Maybe you run a company and your software is not working and someone told you DDD can help. You might be a developer looking to improve. You might be a proponent already. You might be an opponent already. Maybe you are rare and read it once or more rare and read it a couple times and are still looking for more clarity or even validation. Wherever you are on the journey, I hope to come along side you and together sharpen our iron. You may leave comments. I may reply.
The first time I read this book my approach was inefficient. I was looking to primarily write better code. It does help with this effort, but not the way I saw other authors tackle the subject. For instance Clean Code (Martin, 2008) and Code Complete 2 (McConnell, 2004) aim to help us construct code using some best practices learned over many decades in the actual writing of the software and there are myriads of code samples to help. There are relatively few code examples in Blue. This should have been my first clue. Yet I was puzzled.
Each time I read it, something new to me would become more clear.
Knowing what I know now, my approach would be a lot different from the start. This book is not so much about how to master the technical construction of software, though it ultimately helps there, rather it is designed to tune our minds for something even more important.
Blue wants to teach us how to better understand and express the domain.
Why?
You might ask, “What is a domain?” and “Why does a book on software care so much about this domain thing?”.
I can give the text book answer, and I can tell you what I have come to understand about the focus on domain in the real world.
Textbook Answer:
When you understand the domain, then you can serve the domain better because you understand it.
Blech. True. But Blech.
Real World Answer:
The law of entropy, called ‘positive entropy’, enforces that the leaders, stakeholders, developers, customers and code can never be on the same page through natural means. All interested parties will diverge in their understanding by some degree or another and left alone, it will get less aligned over time. To the degree that needs to be corrected, a force must be applied. The law of entropy calls this force ‘negative entropy’. With out this corrective force, businesses suffer code confusion which leads to rewrites.
You can find code tools to sort of help with this, but if you start wrong and travel wrong for awhile on a flight path you are wasting fuel. You might run out of fuel.
DDD is a corrective force that gets everyone on the same page early, dispels lies, uncovers hidden truths and if you reach the right level, you might win a golden ticket to Portland, Maine to enter the DDD factory. Just kidding. There is no factory. Developers calm down. There is a factory.
So if you want a reason to read this Big Blue Series and the Blue Book itself, it is just that. You are tired of the IT to Business disconnect that drives your customers nuts, your developers to work ungodly hours, your business to waste money and potentially — your mental health to be questionable.
You want to be in this flow if you want a better paradigm that gets all the players on the same page asking the hard questions sooner. You will want this when you are contemplating how to deal with new software that can go wrong. And you can benefit from this as a way to wrangle old software that has gone bad in someway or another.
If the vision of the domain itself is corrupt, well, DDD may surface that and help you make even more difficult choices — maybe.
Blue will help with the construction of code, but it does it from a deeper level. Almost philosophical, but still extremely practical in an environment where quality could benefit all parties by design.
There is more. That is why I wanted to write this series. This one point is enough to help you know whether you should continue with me or not. It takes courage to tell and hear the truth. I hope we both have the courage.
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
Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Pearson
McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction, Second Edition. Microsoft Press
