Strategic Domain-Driven Design Kata: Delivericious
If you like this Kata, check out another Kata I’ve published using the example of an online car dealership: https://medium.com/nick-tune-tech-strategy-blog/architecture-ddd-kata-online-car-dealership-540c534121e2
If you would like to learn or practice how to break up a large business into domains and use them as the foundation for your software architecture and team organization, I have created a strategic domain-driven design kata that you may find useful. It’s based on the industry of online takeaway ordering and delivery using a fictitious business called Delivericious.
You can find the Miro board here: https://miro.com/app/board/o9J_l45tkpU=/
The instructions are quite simple: open the Miro board using the link above and copy and paste all of the content into a Miro board of your own. It’s all completely free: there are no pleas for donations or ads for consulting services, and it works with non-paid Miro accounts.
Structure
I’ve structured the board in 4 parts:
- Part 1: Domain discovery
(reviewing a pre-prepared event storm) - Part 2: Designing domain boundaries
(chopping the event storm up into domains/subdomains) - Part 3: Choosing core domains
(modelling the strategy) - Part 4: Designing domain collaboration
(designing end-to-end processes to identify coupling and validate responsibilities)
You don’t have to do all of the sections and you don’t have to do them in this order. Overall it takes about 6–8 hours, but it can easily be partitioned into 2 or 3 smaller sessions. I recommend combining part 1 + 2 into a session, and then running part 3 and 4 each as separate sessions.
Who to invite?
Designing domain boundaries is a cross-functional activity that requires business, product, and tech input, so you can invite almost anyone to these workshops.
Part 1: Domain Discovery
The goal of this part of the workshop is for attendees to get an understanding of the business example they will be working with throughout the Kata. I provide a brief company description about Delivericious and a pre-pared event storm for attendees to review:
The template also includes a domain quiz. Working in groups, attendees will need to review the whole event storm and understand how the business works in order to answer the questions, which then sets them up to start designing the domain boundaries in part 2.
I recommend organising attendees into groups of 4–5 people.
Part 2: Designing Domain Boundaries
In part 2, each group has their own copy of the event storm and first starts by identifying pivotal events and then by drawing domain boundaries on the event storm.
After each activity, a short review of each group’s solution is a great opportunity to discuss alternative design options. This is a key part of the workshop where attendees are discussing trade-offs of various solutions, and seeing other groups produce different solutions. I think this type of discussion is important if you want to build a good design culture in your company.
Part 3: Choosing Core Domains
Part 3 of the workshop usually results in a lot of great opinions and insights. In this part, each group has to place each domain on a core domain chart to determine if it is core, supporting, or generic. These classifications are about determining where a business believes it can gain competitive advantage.
After placing each domain on a core domain chart, attendees are then asked to anticipate how the core domains may change over time, and which new core domains may come to exist.
As with most of the workshop, there are few right or wrong answers. The important thing is the justification attendees use for the choices, and how they have analysed the trade-offs of alternative approaches.
Part 4: Designing domain collaboration
The final part of the kata is about connecting the various domains together in order to map out end-to-end business processes. This step helps to validate domain boundaries and be confident that they make sense as team boundaries and software boundaries. Domain message flow modelling is used for this step.
After each group has modelled a specific scenario, like processing an order, a design review session is next up. Design review is basically a code review but for architecture. Importantly, this activity is again about discussing the trade-offs of various design decisions and helping attendees to improve their analytical and design mindset.
Questions and Feedback
If you have any questions or feedback please feel free to contact me. If you find this technique useful or if you don’t, all feedback is useful so that we can improve the kata or create better ones and make it easier for people to learn and master strategic DDD.
