Pub Talk — Reflecting on the Big Blue Series — First 18: The Basics of DDD
When I was young, I thought all learning is best done in school. Turns out much learning is not anywhere near a college campus. There is a foundational need for learning while in school. We gain abilities to build upon. It is necessary. And it is then forgotten. What is more remembered is our hard-won experiential knowledge. In addition, other gracious people offer their experiences to add to that blend of learning.
I love the process of learning one on one or in small groups. I really like it when there is good food and beverage in the mix. It feels like life because it is. We are born to learn and when we engage, we feel like our purpose is in the process of refinement. It is a good feeling.
What does this have to do with reflecting on the Big Blue Series so far? I was in a coffee house with Nick Tune over in San Diego after a Domain-Driven Design (DDD) meetup before a contract of mine dried up. I was chatting with him about his experiences in software and what it was like to infuse DDD in his real projects. I won’t go into detail, but suffice it to say, I learned a lot about other real experiences in software. Nothing like hearing people do real best practices in real way for good reasons — and it works.
Then my contract dried up and I was wondering, “What have I learned so far? How did it develop? Where is this going?” That is when I chose to look back on the Blue book (Evans, 2004), or “Blue” as I call it in the series, and start writing the Big Blue Series.
Not to worry, I have a new contract signed and the effort to accomplish high levels of supple designs using DDD are about to embark yet again and in an even larger corporation with greater stakes. No pressure! They even wanted DDD by name if you can imagine that!
The Big Blue series is like me sitting with you telling you what I have learned so far as it relates to a kind of school of thought. It is 18 articles (so far at the time of this writing) starting with how to approach this effort. These links will get you started if you are interested:
Big Blue Series — 01 — Approaching Domain-Driven Design
Big Blue Series — 02 — Cracking the Book
See the rest at: https://medium.com/domainintelligencetoday
The articles are in a bit of a peer review process and I am going to update them as I go along, but they were worth assembling and getting out there in the sphere of ideas now rather than later.
Some who read this recent series are far beyond DDD. They know what an Aggregate is and how to craft them with the Entities, Value Objects, Services and Events. They get how a Factory crafts and Aggregate (usually) and how a Repository is focused on insulating the Domain Model from the database model. They know how to detect and put a boundary around a context (Bounded Context) and protect and develop a consistent language inside of it (Ubiquitous Language). They know how to hear what the domain is trying to do and put all they know into making a map, a model of all those things to honor the needs of the Domain as the primary concern — DDD.
Yet some have heard of DDD and have no idea how to even start thinking about it. I know when I started, I was as lost as a 4-year-old in a Japanese train station without my parents. It was safe, but I was not sure what to do or what to think.
But time has passed, and the reality is, there are so many things we can do now to build on top of this paradigm that great thinkers like Nick are working on ways to make use of emerging patterns in DDD. Ways to be more explicit by helping teams become better able to see the model near instantly rather than take months or years to get comfortable with the code. This alone will change everything about how we build software in the future.
Blue is a steppingstone to some key knowledge. It does not have everything, but it has amazing lessons. Other people have written about DDD, and they do a great job, but I have an affinity for inventors. Pioneers. There is not a lot of glory in it because people forget what it took to get to that place. Evans is a pioneer. Sure, he built on the pioneering work of the masters of Object-Oriented Design that came before him, just like others are building on his work after him.
Having said all of that, I think my goal, looking back on the series so far, was three-fold. Primarily, I want to be sure I did not miss some of the critical aspects of DDD. I am surer now than ever, but I still leave room for learning! Secondarily, I wanted to introduce a way to consider setting a foundation of DDD from this book which honors the business vision most importantly, a missing concept unfortunately in many organizations. Third, I wanted to give other experienced DDD practitioners a chance to see if we hold these ideas in common and if so, use it as a fast resource for their teams to build a DDD foundation.
In essence, we still have a lot to learn. As we strengthen the foundation rather than forget about it, it might be what helps us craft a better future. It could usher in the next great invention. Someone is bound to birth another steppingstone. I hope it is you.
Until next time…
References
Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the heart of software. Addison-Wesley Professional
