I finally made it to the DDD - Domain Driven Design Meetup here in Denver and it was a really awesome night. The session was not their standard meetup format as the Explore DDD conference was in Denver - while the conference is only 2 or 3 days, there is a whole week centered around Domain Driven Design with multiple workshops, events, hands-on activities, and much more. I feel really lucky that my introduction to DDD and EventStorming just happened to coincide with this conference as there were a lot of really thoughtful and considerate developers from around the world in attendance to contribute their thoughts and experience.
The plan was a hands on modeling workshop, and I honestly didn’t know what exactly to expect when I arrived. “Hands-on Strategic DDD Modelling and Architecture Kata with Kacper Gunia & Nick Tune” was the title, and the description said it would be a night of hands-on DDD modeling in the domain of loyalty. That we would work in small teams and with an initial set of requirements design a system - the bounded contexts, the domain flows, technology choices, and other architectural details. The description said we would look at some of the tehniques to model domains including “context maps, domain storytelling, the bounded context canvas, and c4 software architecture”, but I don’t recall ever doing an overview to learn those things, so now they’re on my list of areas to look into.
I arrived, we split up into groups, and one of the facilitators handed out sheets with a high level context of the domain and explanation of the requirements. The domain was a fast-casual restaurant chain serving organice meals and beverages. The comapny has decided to introduce a consumer loytalty program with rewards of points and ways to redeem for food options. In our small group we read through the details and what they were looking for - the requirements were a lot around how they wanted points to work, what should happen if the system is down and they want to redeem points, how many concurrent users and new sign-ups need to be supported, and that they wanted to differentiate themselves by tying a credit card to the rewards account so you can swipe to pay and the transaction will be automatically associated with your rewards account.
I am not a developer and didn’t really know how to approach it, I figured I was mostly there to learn and observe, but the developers I was with were DDD practitioners and immediately said “We should do an EventStorm”, I said I didn’t know what that was and the whole group got excited to spread the word of EventStorming. We had some paper hanging up and some stickies “we don’t have orange, so we’ll have to make some adjustments” I didn’t know what that meant, but I later learned orange stickies are one of the main elements of EventStorming, but that will be a topic for a future post.
They told me we pick a color for events (since we don’t have orange), and start writing one event per sticky, in the past tense, using the exact same language that was provided in the requirements sheet. This way we were speaking the same way as the business. Then we started organizing it in a timeline and associating pieces to one other, we started grouping items by drawing cirlces around them. I didn’t exactly understand what we were doing with the stickies, but I did see that we were creating understanding and actually designing the architecture of the system. We had a sense of what parts went together, what might be microservices, what might sit where and how we might hook things up. The design was coming together.
The rest of the night was sort of a weird blur, I wasn’t exactly clear on our desired learning outcomes and it went by pretty quickly. In the end I was mainly just really impressed with these developers and architectures using DDD and how thoughtful they were and how much care and consideration they put into learning about the domain they were supporting and constructing for. I also had this take away that i wanted to learn more about DDD overall and EventStorming specifically. I had never seen a technique that had so much potential to allow for discovery, discussion, and to create a shared understanding and shared language between business and technology partners. I know EventStorming is something I want to look more into and use going forward.