The Unspoken Secrets of DDD: Lessons from Eric Evans

What I learned about knowledge crunching from Eric Evans' Software Design Masterclass

Like any other practices or techniques I learned, I’d like to validate my understanding against the source of truth, and I can’t get closer to the source of truth than attending Eric Evans’ class, a pre-conference workshop in DDD Europe 2024. It’ll be an opportunity to observe the original author of the big blue book, the man himself, operate in real life.

Validating against the source of truth is important for me to reduce misinterpretation. For example, I joined ThoughtWorks 7 years ago to validate my understanding of various Agile practices. I was first exposed to Domain-Driven Design (DDD) at around the same time, but unsatisfactorily until today, I haven’t felt that I have validated my understanding of DDD. That’s what I aimed to do in this class, uncovering Eric’s secrets.

This brings me to the structure of the class. The class was running for two days. There were 2 instructors, Eric Evans and Gien Verschatse, and there were roughly about 15 participants. Gien wore two hats, she’s a software engineer, and she’s also playing the role of a domain expert in DNA building or strain engineering, a domain she worked in for 5 years. Eric, and all of us participants, were to knowledge crunch and model this problem.

I have zero experience in DNA building. The domain is fascinating, but I had to remind myself that I paid a significant amount to attend this class. This means I’m more interested in “domain modelling” Eric’s thought processes than the problem domain itself. I kept 80% of my energy observing Eric.

Given how unstructured the class is, I told Eric that I’m struggling to domain model his head and DNA building together. I’m glad I did that as despite my best effort to read his mind, it was easier when he started to add commentaries about his thoughts.

There were many observations and learnings I’ve made, but to cut the length of this narrative essay, I’ve decided to scope it to knowledge crunching, the hardest, crucial, yet often neglected skill to master in DDD.

Expertise in listening

Despite the plethora of techniques and methods in the DDD community, such as Event Storming, Eric didn’t use any of them. At some point, a group in the class were debating on what techniques to use, and they received advice to use whatever that works for them.

There wasn’t any specially DDD-named technique he was using. Eric spent most of his time sitting and listening. He didn’t hold a notebook. He didn’t draw anything. There were 5 instances where he would stand up, show a gesture of having a light bulb moment, and write a short sentence on a whiteboard. Apart from that, he’s primarily listening.

What strikes me is how good his intuition is for what’s important to capture and expand. He shared his heuristic: “What’s important you’ll hear over and over again.” He’s able to separate signals from noise extremely well.

When a participant asked, “Could we solve the problem by defining DNA pipeline declaratively?” Eric noticed Gien’s reaction, her eyebrow raised, lost in words. Then Eric intervened and suggested using language that resonated, the word declarative was too technical. He’s actively listening, and paying attention to subtle cues.

Expertise in interviewing

Listening is one expertise, he’s also demonstrated how to ask great relevant questions at the right time. During the class, it’s becoming apparent that the participants tend to try to go deep into irrelevant points or understand everything at once.

Like any interview, time is of the essence, and going deeper into an irrelevant topic will waste everyone’s time. In fact, he mentioned that “time” is always in his head, so he wants to be careful about how he spends time with a domain expert.

The room often jumps ahead and talks about solutions, and Eric often refocuses the room on pain points, rather than solutions. I have observed a similar tendency to jump into solutions from many engineers throughout my career.

At one point Gien uttered so much jargon no one understood anything in the room. Eric caught his confusion and executed a manoeuvre that left the room in shock and awe. The class later summarised this technique as “zooming in and zooming out”, which I don’t think captures the nuances of what he did. In his own words, what he did is to “latch” onto a smaller problem, within the big problem that’s been described. This small problem is not known to him, but he felt that he could understand that better than the bigger problem. Once he understood the smaller problem better, which took some time, he climbed back up to the bigger problem with a newfound understanding.

Expertise in learning

“Is this how you would operate in real life? No tools, no notes, no nothing?”, I asked at some point. The answer was a resounding yes. He further expanded on how he doesn’t default to UML either. Instead, he would learn and absorb diagrams being drawn by domain experts.

He’s deeply committed to being immersed in the domain. Never once he would say that he’s trying to domain model, or he’s trying to knowledge crunch, he listens to a problem, and he’s off having that deep conversation to further his understanding.

Understanding requires elaboration, and I was amazed by how much effort he’s showing in elaborating with the domain language. He’s the first one that would verbalise such a sentence, “So we would use THCAS Forward Primer and Reverse Primer on a plate to amplify the gene through a PCR process to create PGAL1.” (I don’t remember the exact details). As you can see, we were in a different world. As far as I can remember, no participants attempted to elaborate like this. Eric was demonstrably struggling, stuttering, and showing pauses, when he was trying to finish that sentence. The result, he learnt the fastest in the room.

---

What I love about the themes I’ve observed is how Eric opened up about the fact that we don’t always need to rely on new methods, but we could get better results by being experts in our basics. These basics, the idea that designers should have curiosity and empathy, were shown in all the observation themes.

Unfortunately, though, I felt underwhelmed by what I’ve learnt. These were the things I already knew, these are no secrets to me.

It took me time to realise that there was an observation that I overlooked. It took me 5 days to realise this and I later shared that one key learning with Eric, jokingly during our dinner: “Eric would like to be the first one who kills his baby, and if it’s not his baby, he’ll cuddle it first before killing it.”

This metaphor was used when we talked about how to deal with an old broken existing domain model that has been created, either by ourselves or someone else. Eric made an important point: Most designers could not come up with good domain models because the designers are too attached to what they have produced in the past. Then he further said:

“I want to be the one who comes up with a better model. I want to be the one to find flaws in my model.”

- Eric Evans

That’s the secret I’ve been looking for. I have not thought of approaching a model in that manner.

That statement itself may sound plain, but it expresses his attitude towards domain modelling, the level of care for domain models he conveyed in that sentence is on another level. Two individuals may practice the same techniques, but they’ll show different results when they care.

If you have a deep belief that a better model will help us solve problems better, you’ll do whatever it takes to produce a better model. And in that belief, I found not just a lesson in DDD, but a lesson in the relentless pursuit of excellence.

---

If you liked this essay, you might like another one about DDD: