Tactical Design by Example - Using Kotlin and Spring Boot (Part 3)

Let's take a look back at my goal

Based on Event Storming and Hexagon Architecture I want to create a set of building blocks, using Kotlin and Spring Boot. These building blocks can be used to assemble µServices that solve real world problems.

I want to clarify what I mean by building blocks. First of all, Eric Evans talks about building blocks in his Domain-Driven Design book. Here's an overview of the building blocks he is referring to (image from Domain-Driven Design and Spring)


Some of these building blocks are first-class citizens in the Spring eco-system, which is a good foundation. However, these building blocks are also quite fine-grained , which only become visible if you model on a very low level. So while we do use them in day-to-day programming, we need something more abstract when exploring a story during a refinement, together with a product owner and potential stakeholders.

A problem I encountered in the past was a gap between high-level, domain-oriented modeling, and a low-level, software-oriented modeling. At our team at REWE Digital, we were frequently surprised by insights which only revealed themselves on a closer look, things that were invisible from a higher, abstract level. That often made our estimations unusable, which is always an unnecessary burden on the trust levels within the team.

A new approach to refinements

We are now trying a collaborative modeling approach to refinements, with several goals in mind

  • narrow the gap between high-level and low-level modeling
  • visualize the model with post-its rather than just describing it verbally or as text in Jira
  • generate more insights early on, by empowering team members to actively contribute to refinements

For now, we do refinements remotely, using a Jamboard. Here is an example from a recent refinement (unfortunately not ready for disclosure)


While a Jamboard is more limited than, for example, Miro, its constraints are quite charming. It is a much simpler tool, with a small modeling space, where you don't get lost. We found it's a good tool for a software-level model. The post-it colors are almost a perfect match for Event Storming.

In the example above, it's quite easy to see that there are actually two parts to the story, so a visualization often hints at options to split stories. You also see repeating cascades of orange, blue and yellow post-its, and also blue and pink post-its. These Event Storming patterns make it easier to create a simpler mental model of a problem, and pave the road to a technical solution.

Now that refinements are a little more low-level, they take up more time, and are more intense. Instead of a single two-hour refinement per week, we now do two refinements, each one hour long. Although the first few sessions were quite bumpy, the feedback from the team is now unanimously positive.

Building blocks revisited

OK, I'm now coming back to the idea of building blocks. The blocks identified by Eric Evans are totally usable, but I need to add more abstract building blocks. Event Storming can help here. In an ideal world, the idea would be to map each post-it to a single task, and map each task to a class that has to be implemented. This would be a perfect bridge between the domain, the domain model, and the code.

In the source code of our µServices you will already find events and commands, and also aggregates. But what about other blocks, like business rules or policies? We still don't have a proper representation for these. Business rules are sometimes just functions in a service, or methods on an aggregate. What about validation? Will this be done before it enters the application service layer, or even within the domain? These are questions that I want to address as we move forward with this approach. So what are your questions?

If you want to be included in the dialogue, feel free to contact me on Twitter.

Move on to part four or go back to part two.