What is event storming?
having looked at what a DDD system looks like structurally, the next question is how do we build these things? How do we design them? The best technique that I know for doing this is something called event storming, which was developed just a few years ago by Alberto Brandolini. I've shown you his book here and also the URL to the book. This is a book that's definitely worth buying and reading. Now, event storming a technique that is used really for two things, but as we just saw in domain driven design, those two things are the same thing. In other words, you can use it to both analyze the domain, analyze the business, and also to develop the code that is going to be modeling the business because by modeling the business you are also coming up with a design for your code. So, event storming then is a collaborative technique that you do in conjunction with business people in order to come up with a design for a system that models the structure and flow of activities within the business itself. It's important to point out that stories are also important here also. Is one of the things that gets people down a wrong track when they do event storming is they try and do too much at once. They try and model an entire bookstore, for example, in one session and that way lies madness is that what you want to do is focus on a specific story and then model that part of the system that you need to model in order to implement that story. Then, once that's more or less done, and in fact if you're working in an agile way, you'd implement at that point, but once that's done, then it makes sense to go back and modify your previous work in order to incorporate additional stories into it. So you sit down with a story and a bunch of business people and a white board and a bunch of sticky notes and you start modeling. Now there are a couple terms that we have to discuss before we even start though. First one being an event. So an event is something that happens at the business level that your customers, or end users, or domain experts care about. It's a business level thing. Remember what we're doing with domain level, domain driven design, is implementing the domain. So, an order having been submitted is an event, a payment having been received, a nightly reconciliation report completed. Now that's an interesting one because it's not a human actor that triggers it. Is that orders being submitted and payments being received is a human actor, but here it's some kind of automated process that's triggering it. We don't really care who's triggering the event. What we care about is the event itself. Also notice that the events are specified in past tense and that's also important. An event is something that has happened that will trigger something else to happen next. So putting the events in past tense is a good way to keep them straight, is a good way to organize the system linguistically.