Q&A after the talk at TDC 2025: Practical Domain-Driven Design

The most important question in software industry today is….

“Who is the User?”

If you are curious about the claim I am making then please check the recording of my presentation at TDC in Trondheim this year.

Here I will elaborate more on two of the questions I got during the talk.

Q: At what point during the exploration of the domain, did you start on an implementation that restricted the changes to the domain model, and in hindsight, what would you do differently?

Answer: Very good observation on coding decisions that, once taken, can restrict further exploring another option on the domain model.

Well-crafted boundaries, on the technical level, are great tools to help teams provide options while exploring the domain. That is one of the real powers of Bounded Context, one of the central concepts in Domain-Driven Design.

To avoid slowing down or narrowing the solution space too soon, one approach in DDD is of particular use:

Create a boundary for experiments without affecting the rest of the system.

In our case, see the slides with the case study, we built a boundary between two role-based business processes, Group Planning and Group Check-in. We decided to start with the simplest one, Group Check-in, where we were quite confident that our hypothesis about the boundary was a solid one. Moreover, we knew that we were able to deliver that part of the system fairly quickly and get confirmation from production.

In the beginning of the project we concentrated the coding efforts solely within the Group Check-in context while at the same time we continued exploration in the Group Planning context. That allowed us to simultaneously play with multiple hypotheses on the part of the system that was not deeply understood, while continuing production-level coding on the more simpler part.

Q: Have you successfully applied Event Storming, and if so, what was your biggest take away?

Answer: As the established go-to technique in collaborative modeling sessions, Event Storming can lay groundwork for insights hardly possible to get with other approaches. My personal attraction to Event Storming is its nearly perfect ability to model Time explicitly.

There are so many systems that fail to take Time into account. That is why they need to deal with complex failures that arise precisely because of an intricate sequence of otherwise straightforward operations. Event Storming is great at exposing this.

One particular Event Storming session from the domain of healthcare comes into my mind related to this challenge.

We were modeling the process of incoming referrals in hospitals, the usual case being the general practitioner referring a patient to the hospital. To almost all of us the term Referral meant precisely that. However, for some complicated health issues a patient could be referred again from one hospital department to another or even to another hospital. Modeling the difference between incoming and outgoing referrals was very obvious when walking the timeline during Event Storming. It simply turned out to be several different models instead of just one generic Referral.

An insight like this was very difficult to deduct just by talking to domain experts since they tend to use the same term for all the different cases. Being able to model the process on the timeline with Event Storming opened up a new perspective on the changeable meaning of the concept as the time passed.

For quick reference on the particular case study from the talk, the slides are available below.

Hopefully you will find the claim about the most important question in software industry gets justified after watching the talk!