Interactively Implementing a Domain Model

Insight

  • Conference workshop
  • Conferences

A report on our hands-on lab at Domain-Driven Design Europe 2023

Hands-on labs have always been a highlight of mine during conferences. It offers participants a unique opportunity to learn and engage with new Domain-Driven Design concepts that sometimes they don’t have a chance to deep-dive during their day-to-day roles.

On June 8 at DDDEU23, Michel Grootjans and I kicked off our hands-on lab with an engaging coding workshop titled: “Interactively Implementing a Domain Model”.

As we entered the room, we were thrilled to see a full house of 72 enthusiastic participants. We encouraged them to form pairs based on their preferred programming languages, which ranged from Java, C#, JavaScript, TypeScript, PHP, Python, to F#.

Pairing not only facilitated a collaborative learning environment but also fostered knowledge exchange beyond the workshop.

DDDEU23 handson lab (2)

After a short introduction, participants delved into the exercises from domainmodelling.dev, a made-up but realistic challenge created by Michel and me.

The hands-on main challenge was to implement a domain model for calculating the price of a recycling centre. Every time you drop of garbage at the recycling centre, the amount of garbage you dropped is weighed. Depending on the type of garbage you have to pay a certain amount. Of course, there are more rules that make this domain more interesting.

Goals and outcomes

With this workshop, our goals were twofold:

  1. We wanted the participants to have fun

  2. We wanted them to gain valuable insights into the intricacies of domain modelling in code

It was interesting to listen to the diverse viewpoints and experiences from the participants. For starters, since most of the pairs were using different programming languages, the way some things were solved was different. Some people used the type system more, others a bit less. Some went for a very functional style of solution.

The other main difference was that people had different levels of experience. Some were encountering domain modelling for the first time and focused on grasping the fundamentals, while others, with more experience, delved deeper into the challenge. For example, some people who were really new, didn’t focus too much on the ubiquitous language or tactical patterns, but after some discussion with us or by letting using the guiding questions from the online exercise, they noticed that the UL is really important. And that starting with some basic value objects was a good way to model their first steps.

On the other hand, more experienced people were moving a bit faster through the first exercises and only started refactoring into a domain model when they felt they understood the bigger domain more.

DDDEU23 handson lab

As the workshop drew to a close, we conducted a quick feedback round. Participants expressed their enjoyment of the hands-on experience and posed several thought-provoking questions.

One question that often pops up, is that people want to see the solution and that’s something Michel and I are reluctant to provide, because there is no single solution and we definitely don’t claim to own the best solution. Every programming language has different styles and every time you solve this you’ll come to different insights.

The best solution is something imaginary that depends on a lot of context. The thought processes and discussions during the implementation are much more important. That’s why we don’t provide a solution.

We do try to give some direction on the solution. For example in this live coding session that I gave at KanDDDinsky you can see my thought processes going into a refactoring of the recycling centre domain in this video. Next to that, you can also watch our Domain Modelling video tutorial, where you can see how we worked on a similar problem.

Overall, two hours is often insufficient to cover multiple learning objectives in great depth. Thus, we prioritised imparting practical knowledge of domain modelling over theoretical explanations.

We wanted them to take something back that they could quickly implement in their daily tasks. But our ultimate aim was to inspire participants to further explore and refine their domain modelling skills.