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 various 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 do so. This is especially interesting 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 past believes and rediscover. This recounting of our journey is not one for a single post, so this is the second in the series. Read the first post if you haven’t already.
Decomposition
After our initial big-picture event storming sessions were mostly done, we decided to move towards decomposing our domain into subdomains and bounded contexts (remember, we are following along with the process outline by the DDD crew).
So out came the yellow tape and markers! (metaphorically at least, as a lot of these sessions were online due to the corona measures)
It was interesting to see how we were very fast to spot the most pivotal events and system boundaries, but just like before, most discussions centered around only a small number of boundaries, because those were the least clear to most people. A ha! Those are exactly the kind of discussions we should be having to joinedly discover more about them.
One interesting point of conversation was around the “Private listing created” event. TicketSwap allows sellers that have already found a buyer, to create a private listing for this buyer. That means the listing is still sold through TicketSwap (with all our safety promises), but is reserved for that buyer specifically. This of course has some interesting implications after listing creation for other system processes we do for “regular” listings, like sending out ticket alerts. Another discussion evolved around draft listings; right now a new draft listing is created when an event is selected, followed by uploading a ticket. However, we’re rolling out an update for mobile clients, which allows sellers to upload a ticket via the share sheet, and select an event after that. So which event should be the pivotal event? Should both be? For our current mental model, either choice had no real impact, so we decided to leave it. But these are the kind of discoveries that can turn all assumptions upside down.
Context repetition
During the decomposition of the big-picture event storm, we also noticed some areas that were very similar. For example, TicketSwap offers a secure connection with ticket providers for a system we call SecureSwap™. This connection is used during listing creation to make sure the ticket is valid. But it is also used during order fulfilment to actual “swap” the orginal ticket for a new one. Even though this is used in two different contexts, it still belongs together. Where it became troublesome was with the new business development mentioned at the beginning, which kicked off our entire (re)discovery journey; we were unsure whether this new development was part of the SecureSwap bounded context, or if it was its own thing. In other words: is it the same, or is it similar? Although it was reusing some of the same events and business rules, it also added some of it’s own and ignored some others.
Same thing, or just similar? By Bruce Worden
This is where we finally got to the core of the problem. This entire discussion would decide how we would view the new business development, and how we would eventually represent it in code. After a lot of back-and-forth, we decided to consider it two separate bounded contexts that might have a connection, but are not the same. For now, and until we discover more about it, this is good enough.
Next time, we’re diving deeper into the relationships between the bounded contexts, and will see if our decision holds.
