The first objective in event modeling is to capture the narrative of your business process as distinct events. Doing so will create the context for the rest of the process the same way a script sets the context when producing a film. We'll begin by defining what an event is, and then we'll proceed to brainstorm, and then sequence these events into a plausible story. So what do we mean by business event? A business event is the record of an important business occurrence, decision, or outcome. At this early stage of the modeling process, let's forget about software and systems, and instead think about record keeping, with paper, snail mail, et cetera. We can ask ourselves, "What set of outcomes would I have to write down in order to keep track of this business process, if I was using paper and pencil?" These events have a name or a type, as well as a data payload, which we'll talk about more in just a bit. The sequence or stream of all such business events comprise the causal narrative of a bounded context or a business domain. For example, in our autonomous vehicle ride sharing app, Autonomo, we might have an event representing the decision to match a requested ride with a specific vehicle. The event name or type might be "Ride Scheduled", and the data payload could include the ride ID, the rider's user ID, the vehicle's identification number, the pickup and drop off locations, and the pickup time. Using this example to guide our thinking leads us to the conclusion that events must be de-normalized and data covering, meaning all data necessary to understand the business process is contained within the events themselves. There's one exception to this rule for large blobs of binary data like images, sounds, or videos, that we don't want bloating our event storage. In this case, we can use the claim check pattern, where we store the blobs in a separate location from our event store, and then include the URI for retrieving the blob in the event data, rather than the blob itself. All other data should be included in line within the event. Now that we've settled on a definition of business event, let's capture some in our event model. The first step is to brainstorm our events. The goal at this step is broad participation, and there are no wrong answers at this stage. Invite the participants to write verb phrases in the past tense on orange stickies, and get as many on the board as possible in a fixed period, say 15 minutes. Here's what our autonomous ride share model might look like after the first step. Lots of events, out of order, probably some duplicates and wrong answers, but it's a great start. Our next task will be to sequence these events into a plausible narrative, add in missing events, and eliminate duplicates and non-events. The participants should be able to roughly sequence the events pretty quickly, perhaps in 10 minutes or less. Then it is often useful to invite one participant to walk backward through the rough sequence, to check the plausibility of the story with the whole group. Often at this step the group will identify and add some missing events. In our first event brainstorming step, getting active and broad participation is more important than getting precisely correct events. However, as we sequence and filter our events, it is important to distinguish what is not an event, so we can replace or remove them. Business events are not usually low level UI or system events, like a user mouse click or the arrival of a TCP packet. These are usually too low level and fine grain to describe an important business outcome. Of course, that is unless these are your business domain. For example, if you're building a user analytics or security app, then you might need to record user clicks or TCP packet arrival as a part of that domain. In other domains, low level system events might combine, or roll up into business events. Another common non-event is a query, view, or notification of current state. We'll almost always capture these as read models. One exception might be a business-driven snapshot event that captures a moment in time, such as a monthly closing of the books in banking. Finally, most requests from users to change the state of the system are in fact commands and not events, especially if we can immediately decide what to do about that request. So as we step through the model to check the narrative, we can also remove non-events or replace them with a placeholder green read model sticky, or a blue command sticky. Here's our ride share example, after sequencing and filtering our events. Notice how the sequence of events reads like a plausible story, and doesn't involve any low level software or systems concerns. We've completed step one of our event modeling process, by capturing the business narrative as a sequence of events. This narrative acts like the script of a film, by setting the major plot points, and focusing the group's understanding of the problem to be solved. In our next step, we'll create a storyboard from this script by adding the visuals, illustrating the user experience. If you aren't already a Confluent developer, head there now using the link in the video description to access other courses, hands-on exercises, and many other resources for continuing your learning journey.