Week 9 – Making Implicit Concepts Explicit

It was a busy day for sports fans today with Silverstone circuit, the 5th day of the Edgbaston test and Wimbledon but it’s time we get back to our beloved book. Hope you had a few results go in your favour! We will be discussing Chapter 9: Making Implicit Concepts Explicit.

This chapter struck a somewhat different chord. It brought to mind the silent times in projects when an element that was always present but out of reach is given a name, and the entire design becomes apparent. As stated by Evans:

“It finally snaps into focus. But it starts with recognizing the implied concepts in however crude a form.”

It feels very genuine that deep models are developed by listening, refactoring, getting corrected, and simply paying attention to what feels awkward rather than by making creative leaps. That tension is something I frequently experience, particularly when I’m modifying code to make room for something that doesn’t quite fit. I simply never gave it any thought: perhaps it’s not appropriate because the concept isn’t there.

One line that really stuck with me was:

“When the users or domain experts use vocabulary that is nowhere in the design, that is a warning sign.”

It brought to recall instances when I overlooked domain phrases because I thought they were “just business lingo,” not understanding that they were actually the key to a more organised model. This chapter calls for a certain level of humility: to truly listen to the domain rather than advancing code.

The examples, particularly the “Itinerary” narrative, also made me nod my head. I have witnessed the developer’s arc, which begins with “we already have this data” and concludes with a new object connecting two important systems. When someone casually mentions something, you realise that your code has no name for it, even though you thought the model was “done.”