What is event storming?

 

What is event storming?

Selecting transcript lines in this section will navigate to timestamp in the video

 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.

What is DDD?

 

What is DDD?

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] So let's dive into the details. Domain-driven design was developed by Eric Evans back when dinosaurs roamed the earth, which means that things like microservices and agile didn't really exist at the time. Microservices brought domain-driven design back to the fore because as it turns out, it's an almost ideal way to design a set of microservices. That said, the original work was done in a non-microservice monolithic world, which is to say that the techniques that we're going to look at work just as well in the monolith as they do with the set of microservices. I will however talk about microservices later on in the course. Eric's book is a good book but it turns out there's been some work done since then. So if you're going to supplement this class in order to dive into the details, and you will have to do that because the class doesn't cover all the details, I strongly recommend Vaughn Vernon's book called Domain-Driven Design Distilled. It covers all of the critical stuff that Eric's book covers but it's a little bit more up-to-date and it's a little bit more concise. And both of those are good things. Now, what is domain-driven design? It has several characteristics, the first of which is that it is a collaborative process. Now, the quote here, "Business people and developers "working together," comes from the agile manifesto, of course. So one of the other characteristics of domain-driven design is that it is very, very appropriate for an agile workflow because the underlying philosophy of DDD and the underlying philosophies of agile are almost identical. So step one is that it's collaborative. Step two, characteristic two, is that domain-driven design is built on the notion of modeling. The basic idea is that the structure of your code should model or map to the structure of the domain within which the problem is being solved. So your domain might be accounting, it might be a storefront, it might be anything that makes sense to business users. And the idea is that a business user should be able to look at the overall large structure of your system and make sense of it. That means that when changes happen in one place it's easy to make changes in the other. And that's one of the main advantages of a DDD approach. In other words, changes happen in the domain. They don't happen in the code, they happen in the domain. So when that happens, you need to be able to get the equivalent change in the code as easily and as quickly as possible. If there is a one-to-one mapping between the code and a domain, when a change happens in the domain you know exactly where to look in the code in order to make that change. The third characteristic of DDD that's important is that it's incremental. Now, the basic idea of an incremental approach is that you don't come up with a big architecture up front before you do any coding. Instead, you come up with just enough architecture to solve the problem that's right in front of you. Then as you implement that, you learn more about the problem. And that means that you have to go and change the architecture in order to accommodate whatever new things you learn as the code evolves. That's the agile way of working, of course. DDD was designed with that in mind. The basic idea then is that a domain-driven design architecture will allow your code to grow incrementally over time because the architecture itself grows incrementally over time. Now, what makes that work is the fact that the domain itself provides an architectural coherence that you wouldn't have if you were just looking at things like the hardware. So the DDD approach then lends itself to incremental development. Now, of course the domain is going to influence the system. And we're all very much aware of that. It is the things that happen, things that, changes that are made in the domain influence the underlying software. What we don't think about though, which is equally important, is that this is really not a linear process. As the domain influences the system but the system also influences the domain. In other words, DDD is designed for a world in which you are releasing incrementally. So what that means is that every time you release into the actual domain, users will use the code that you just released and that will change the domain to some extent. So there's actually a cycle here is that you create a little bit of code, you release the code to your users, your users start using that code, and that changes the way they work, which is going to cause other changes to happen within the system itself. It's a cyclic process. So DDD is again very appropriate for that sort of cyclic working because again, what you're modeling is the actual domain that's actually in front of you. And changes are easy to make because there's that one-to-one between the domain and the underlying system.