November 1, 2016
While developing the first MozaicLabs product, eventrix.co, we wanted to use our full experience in agile, lean and software craftsmanship. Here’s a list of things we’ve adopted:
- A kanban process to have a steady flow of features and to allow improvements
- A technical strategy
- Continuous delivery and automated testing from day 1
- Impact mapping to create a development strategy
- Story mapping to slice features and to understand our progress
- BDD to clarify features before starting developing.
- Domain modeling as an important part of the design process, to reduce waste caused by lack of domain understanding.
Then, we started innovating by introducing design elements to preserve consistency of software design. We realized at some point that the team needed more experience with domain modeling and created a new practice format: a domain modeling kata.
Domain Driven Design
Domain Driven Design, or DDD, is a mindset for software design and a set of patterns that support it. The idea is to “tackle the complexity at the core of software” by clearly identifying the domain of the problem and the relations between domain entities.
Like anything related to design, DDD is hard. It requires a lot of experience, practice, and skill. Practitioners need to be very careful with nuances and iteratively work through the domain model until it’s quasi-correct. This is probably why subsets of DDD evolved, with more specific constraints: CQRS, event sourcing etc.
At the core of DDD are understanding and modeling the business domain.
Our kanban process allows us to notice when things take longer than expected and adapt the process to the new reality. We noticed that we had to add tasks to change the domain model. These tasks took up to 10 days, much longer than our usual 2-3 days cycle time. They fit in what’s called “failure demand” in lean / kanban (doing something again because you haven’t done it right the first time). This delay was due to other factors as well, like learning how to write schema migrations at the same time with implementation. But the root cause seemed to be a lack of understanding of the domain model.
As lean thinkers, we asked ourselves: what can we change in the process to make things better? The solution was to add a domain modeling step to the design process, to be done whenever working on new features. Being a new skill, we realized that the team needed more practice. Obtaining good domain models is not trivial.
And this took us to the next step: practicing domain modeling. That’s when our years of experience with software craftsmanship training paid off. We immediately thought about using a kata format for practicing domain modeling.
For those who haven’t heard of it: a coding kata is a repeatable exercise that involves writing code within certain constraints for a fixed period of time and then making a retrospective on the session. Typical coding kata examples are:
- computing the bowling score by using Test Driven Development (TDD)
- refactoring a code base that’s already covered with tests
- adding tests to very messy code
A typical time limit is 30′-45′, but it can be longer depending on the problem. Coding katas can be done alone, in a pair or in a group where more pairs write code and compare results. Other similar formats like coding dojo and code retreats emerged from similar ideas. The retrospective is the moment when the programmers reflect on things like What went well? What was difficult to do? What can be done differently next time? etc.
The domain modeling kata applies the same line of thinking.
The domain modeling kata starts by setting a few things:
- The timebox: we tried around 2hrs, but it depends on the group and the domain complexity
- The problem: we tried “a tool for kanban” and “a saboteur game” and a few core features (e.g. for kanban: create a board with columns and swimlanes, add work items, advance work items, create cycle time distribution report). The problem has to be from a domain well understood by the participants
- The tools: it’s important to be easy to erase and move things around. Stick post-its on a surface or use a whiteboard for each group. We recommend against using digital tools because they impede collaboration in the group (one person will be at the keyboard, instead of everyone writing on post-its)
- What we’ll do: we’ll create a domain model for this problem, meaning domain entities, relationships, bounded contexts and constraints
Split into groups of 2-4 people. Using the tools, create a domain model using the following steps:
- Brainstorm domain entities
- Add relationships
- Add bounded contexts
- Add constraints (e.g. invariants)
- Review the model using the core features requested
This process is not linear. When adding relationships, you’ll probably discover that one domain entity is actually a combination of domain entities. When adding bounded contexts, you might need to duplicate domain entities. etc.
At the end, we do a retrospective, in two parts. The first part is showing and tells: each group will walk us through their domain model and the other groups ask questions. The second part is looking back at the process. Open questions help; here are some examples:
- What was difficult to do and why?
- What surprised you?
- What did you discover during the process?
- How would you apply this at work?
We’ve done this three times recently: twice in the company and once at SoCraTes. During the SoCraTes practice, the attendees enjoyed it. Here are a few learnings:
- identifying the bounded contexts is the hardest part
- using functional use cases as starting point helps with the bounded contexts
- this exercise can be used to develop a common language between the development team and the business team
- when doing the kata with multiple groups for the same domain, there will be big differences between models of each group
In the pictures bellow, you can see the differences between 3 models of Slack application domain, done by 3 groups at Socrates.
It needs experimentation before it can be widely used. Some recommendations to implement it yourself are:
- try more problems until you find a set that is easily understood by most developers
- run it with different groups and document the results (including impediments)
- clarify each step of the kata
Domain modeling is a software design practice that cuts down failure demand from software development. At the same time, it’s a new skill for many developers. Using a kata format to practice this skill proved very beneficial for developers. However, the format needs more experimentation to become widespread.
Will you run a domain modeling kata in your team, company or community? Why? Why not? Let us know in the comments.