For a while now, we have been using Domain Driven Design (DDD) at TicketSwap to help us guide the design of our software systems. This is a messy journey, and certainly not one that is over yet… not by a longshot. Throughout our journey we’ve revisited different believes we’ve held about our domain and business rules multiple times, and we are continuing to discover new and different things every time we revisit our mental models. Specially when new people join our sessions that come with interesting questions and insights.
Very recently we’ve had a new business development that again questioned our mental models, and specifically how this new business idea would fit in there. So, we thought it was time to revisit and rediscover. This is a recounting of our journey. This is not a journey for a single post, so this is the first in the series.
Starting out
In the past we’ve always leaned on the experience and expertise of a handful of people within our organization to guide us through our journeys. That worked well, and gave us lots of insights and learnings already. But this time, since we were talking about big picture stuff, we decided to follow along with the starter modelling process that is outlined by the DDD crew. This starter gives all the resources you need to go from high-level discovery, towards lower-level designing, and has been a very natural guide for us.
As with so many things in life, when starting with a new and unknown process for the first time (for example, neither of us ever worked with a Bounded Context Canvas before), it was hard and at some times awkward. But we persevered and consistently we felt a sense of accomplishment and renewed insights, which sparked all kinds of new energy and avenues to explore further.
Understanding
During one of our previous Discovery Days (something for another post, or feel free to message me personally to ask about it) we had already gotten a company-wide understanding of the new business idea, which helped us understand things like the value proposition, revenue streams, partners, customers, etc. Next to that, we’ve also already created an MVP.
So, we started out by doing a big picture event storming sessions, so see where this new business idea would fit in. The team was already somewhat experienced with event storming on a more detailed level, but thinking more abstractly, on a higher level, is something you need to get the hang of a bit. We started out modelling a small piece all together, which set the example of how high the level should be. Then, we stormed the events that we thought were relevant on that level of abstractness. As the discovery team consisted of people from multiple different teams, it was interesting to see people sharing their insights and expertises about certain subdomains. It also showed us exactly where we were missing some expertise and it already lead to some knowledge sharing.
On eagerness
Even though we all had a mental model about what events are important to our platform, gathering it into a single model still took quite some time. Discussions were had, discoveries were made, and already we started seeing that some assumptions we made about this new business idea and how it fitted into our little world might not’ve been entirely true. Probably because we were eager to learn more, and had some experience, the team was able to swiftly identify sub domains and bounded contexts. Later on, it turned out we jumped ahead too far too quick though, and had to reexamine and decompose again. A good learning for myself at least, to not want to go too fast. This is a big trap, and it can be tough to see when you’re going too fast, or if it’s possible to speed up. But that’s all part of the discovery journey.
