Introduction

Event Modeling has emerged as a powerful method for designing Business Information Systems, ensuring alignment between business teams and development teams. It also enables a modular design approach, where independent teams can develop functional "slices" in parallel, shortening time-to-market at a fixed cost.

Although the strength of Event Modeling lies in its simplicity, mastering it can require significant effort and time. However, AI-powered tools are now transforming this process by generating a fully detailed event model from any workflow description in minutes. This accelerates system design while maintaining structure, clarity, and close collaboration with domain experts.

AI is also revolutionizing the implementation phase, allowing code to be generated directly from an event or domain model.

At DDD Hungary, Staffan from Qlerify demonstrated how AI can streamline Event Modeling by automating both model creation and code generation. You can watch the first 45 minutes of the presentation in the video below. However, this article offers a more complete and up-to-date walkthrough.

‍

This guide offers a step-by-step approach to Event Modeling in Qlerify, drawing on the core concepts from Adam Dymitruk’s original Event Modeling post—including the automation and translation patterns. We won’t detail all Qlerify features here, as you can find more information in our article on Event Storming and DDD (links provided at the bottom of the page) as well as in the in-app help texts.

We'll cover the seven steps of Event Modeling and recreate the example presented in the blog post "What is Event Modeling?". While some visual elements, such as the "waterline," are presented differently in Qlerify, we've successfully applied Event Modeling in many cases using the approach presented here.

Now, let’s dive in. Ensure you're logged into Qlerify with a blank workflow open and review the following Card Type Settings:

• Open the workflow settings by clicking the cogwheel above the empty workflow diagram, then navigate to the Cards tab.
• Under the Use AI heading, ensure that Command, Aggregate Root, Read Model, and Given-When-Then are selected.
• Under the Command heading, ensure that Command is selected.
• Under the Aggregate Root heading, ensure that Aggregate Root is selected.
• Under the Read Model heading, ensure that Read Model is selected.

You can also navigate to the AI tab and pick your LLM model of choice. For this walkthrough, we used OpenAI ChatGPT-4o.

Step 1: Brainstorming

Brainstorm state-changing events together with your human colleagues and AI. Use the prompt below or describe your own scenario to let AI assist in brainstorming.

The workflow is based on the hotel website described in Adam Dymitruk’s original 2019 Event Modeling blog post. It represents an Event Model for our hotel chain, enabling customers to book rooms online while allowing us to manage cleaning and other hotel operations. Include the following steps: 1) Guest registered an account. 2) Manager added a room. 3) Guest booked a room. 4) Manager prepared the room. 5) Guest checked in. 6) Coordinates sent from the guest's GPS. 7) Guest left the hotel. 8) Guest checked out. 9) Guest requested payment. 10) Payment succeeded.

In the empty workflow, click on "Generate workflow with AI," paste the prompt, and then click "Generate workflow" using the default options.

Wait for the process to complete. You should now see something like this (although differences are expected when using generative AI):

Step 2: The Plot

In this step, we'll review the timeline and ensure it creates a coherent story composed of events. This time, AI generated two swimlanes—GPS Device and Payment System—which seem to represent systems or bounded contexts rather than actors. In Qlerify, we typically use swimlanes for roles such as Guest or Manager, not for systems or bounded contexts. Since these steps are automated (as we know from the blog post), we can consider Automation an actor.

• Add a lane called Automation and move Sent GPS coordinates and Payment succeeded to Automation.
• Delete the lanes GPS Device and Payment System. Hover on an empty lane to display the delete button (🗑️).

From the blog post, we know that there are two more automated events: Left hotel and Checked out. Move these events as well to the new Automation swimlane. Now, our workflow looks like this:

Note: The arrows between events represent a plausible timeline but do not indicate that each event automatically triggers the next. They also do not enforce a strict sequence in which the events must occur. Instead, they provide an example of how events typically unfold within the organization.

Step 3: The Storyboard

For each event we'll create a UI mockup of an input form that the actor fills out and submits. If an event is an automated step, imagine it as a robot filling out the form and pressing a submit button.

1. Click on the first event: Registered account.
2. Open the sidebar and select Data Fields.
3. Under the diagram, select the Domain Model tab.

Inspect the Command in the blue box under Domain Model. The form in the sidebar is rendered based on this Command. By adding, updating, moving and removing fields on the Command, you can update the UI mockup.

Ask the question: "What does the input form look like when a guest registers for an account?" Update the Command based on the answer. Here we only do one change :

• Change sort order so that Phone Number appears after Full Name (by using the drag icon on the left side of the field).

Step 4: Identify Inputs

In this step we simply give a name to the command that will be invoked when the form is submitted. The command name is already suggested by AI as Register Account, so if this looks fine we can move on.

Step 5: Identify Outputs

Although this step is called "Identify Outputs", we will think of it as data provided before invoking the Command, basically output from another earlier event. We refer to it as the Read Model and consider the Read Model as being consumed before the Command is triggered. This approach centers the discussion around a single actor.

Ask the question: "What information does the guest need in order to register an account?"‍

The Read Model would likely include information such as Terms & Conditions, Privacy Policy, Benefits, etc. Just like with a Command, you can add, update, and remove data fields from the Read Model.

Note: Whether you see the Read Model (or state view) as the output of a Domain Event or as the input for another is simply a matter of perspective.

Note: An Event should have exactly one command associated with it, but it can have multiple associated Read Models.

Apply step 3, 4 and 5 to all events

Now, iterate the steps 3, 4 and 5 for all events. Here we provide a few key examples that cover all the most common patterns.

Manager added room - Regular Input Form

Click on the event Added room. This step, like the previous one, uses a regular input form. However, it's tailored for the manager to add rooms to the booking system.

• Input Form and Command: The form shows how the manager enters room details. It will likely include fields such as Room Number, Room Type, Price per Night, and Amenities. You can update the form by updating the Command in the blue box.
• Read Model: Now, consider where the manager obtains the room information. Is it sourced from another system, or perhaps from a paper catalog? What information is included? This is a good question to ask the manager during a workshop. Here is an AI generated example of the Read Model:

Guest booked room - Regular input form

This step features another regular input form, designed for the room booking process.

• Input Form and Command: This form should contain the necessary input fields for booking a room, like Check-in Date, Check-out Date, Guest Count and Room Type or Room Number. The Room Type or Room Number is likely to be picked from a list. We cover how to model this in the Domain-Driven Design article (linked in the footer).
• Read Model: The Read Model should contain a list of available rooms or room types, complete with descriptions and prices, and filtered by availability.

‍

Sent GPS coordinates – Integration with an External System

Let's jump ahead to the Sent GPS Coordinates event. This Event is the first of two steps in integrating with an external system (the second step is Left hotel). Unlike previous events, it is not triggered by a human but is automatically initiated by the guest’s mobile device. Because this interaction occurs outside our system (unless we are also building the GPS Tracker), it functions as a black box.

For external events, delete the Command and the Read Model (using the bin icon that is displayed when hovering on the Command and the Read Model). We keep the Event for reference, and we keep the Entity, but do not model the inner details of either the Command or the Read Model. Detailed modeling will happen in the following Event, where we receive this Domain Event, and where the Read Model will contain the incoming data.

Left hotel – Translation

This Event is automatically triggered by the preceding external event, Sent GPS Coordinates, and does not have a visual input form. In Event Modeling, this step is referred to as a Translation. It receives coordinates and interprets them to determine whether the guest has left the hotel or not. If the coordinates indicate that the guest has left, the Left hotel event is triggered; if not, the Event is not triggered.

• Read Model: Here the Read Model is not a query. Instead, it represents the data from the incoming Domain Event received from the GPS tracker (for example, longitude and latitude). The translator's job is to interpret these coordinates to determine if the guest has left the hotel and, if so, to associate details like the booking number, guest name, and departure time. We can use the generated Entity named Location to represent the incoming data. Do the following steps:
  
  • Delete the generated Read Model.
  • Create a new Read Model and select the Entity named Location.
  • Press the AI button (with tooltip "Generate fields with AI") to pick up the fields or use the field selector.
• Command: This represents the Command that we invoke when a guest leaves the hotel. As parameters, we only need Booking Number, Guest ID, and possibly the Time of Departure.

• To make it clear that logic is needed here, for the automation, to determine if a guest has left the hotel or not, let’s add a GWT scenario:
  • ‍Given a guest has opted in for GPS tracking
    ‍And we have received GPS coordinates from the guest's mobile device
    ‍When the GPS coordinates indicate that the guest has left the hotel
    ‍Then the status of the guest's booking should be updated to "Guest Left Hotel".

Checked out guest – Automation

Now, we arrive at the Domain Event Checked Out Guest, another automated step that requires no manual input.

• Read Model: The Read Model represents a query that retrieves all bookings eligible for checkout. This query returns a list of bookings, on which additional checks can be performed. When a booking meets the criteria, the Check Out Command is invoked.
  • Select the Entity Booking on the Read Model.
  • Use the field selector to select the relevant fields and delete the fields not needed.
  • Mark the field Check-out Date as a filter.
• Command: The Command is straightforward. The Command is named Check Out, and its arguments will include details such as Booking ID. The Command updates the booking's status to "Checked Out", thereby enabling the final payment from the guest.

• GWT (Given-When-Then): As before, you can use a GWT scenario to clearly describe the criteria for an automatic checkout.

Payment requested - Manual form

At this stage, the payment can be processed, and when the guest opens the booking next time, a form to complete the transaction will be available.

The input form should capture approval for processing the payment.

Payment succeeded - Automation

The Payment succeeded step is automated similarly to the Checked out Event, but with one key difference: in addition to reading a query and invoking a Command, it involves an outgoing call to an external payment service provider. This call must succeed for the Payment succeeded Domain Event to be triggered. Although this outgoing call isn't explicitly modeled here, we'll describe the success criteria using a GWT (Given-When-Then) scenario.

• Command: The Command (Payment succeeded) updates the booking in our own system after a payment is successful. The parameters typically would include: Booking Number, Guest ID, Amount, Transaction Time, Transaction ID.
• Read Model: The Read Model involves a query that retrieves a list of payment requests. This query might return fields such as: Booking Reference, Total Amount Due, Payment Method.
• To clarify the conditions for a successful payment, consider the following GWT:
  • Given that a payment has been requested for a booking
    When the amount to be paid is successfully captured from the guest's payment card
    Then the invoice should be updated as "Paid".

Note: This step can also be modeled explicitly in two steps, one step for the Command invoked on the external service and one step for the Command storing the result in our system.

Step 6 - Apply Conway’s Law

Now it's time to organize the system's parts into autonomous components. This step is visualized slightly differently than in standard Event Modeling, although the underlying concept remains the same. Switch over to the Domain Model tab and assign Bounded Contexts to the Aggregate Roots.

Following the original blog post example:

• Assign the Entity Guest Account to the Bounded Context Auth.
• Assign Room and Booking to Inventory.
• Assign Payment to Payment.
• Assign Guest Location to GPS

Now you have establish clear boundaries between decoupled parts of the system.

Step 7 - Elaborate Scenarios

We have reached the final step of Event Modeling. Qlerify not only helps you write the GWTs but also lets you prioritize them into iterations, all while maintaining a complete view of the end-to-end flow and understanding how prioritization impacts it.

To proceed, navigate to the User Story Map tab under the workflow diagram. Here, you'll see each GWT lined up under its corresponding Event. You can add additional GWTs using the sidebar or the button at the end of the page (make sure to select an event first).

Assign release

Define the first iteration of your project by selecting which GWTs should be assigned to Release 1. Notice that the selected GWTs move up into a separate horizontal section. You can also add GWTs to Release 2 and rearrange them by drag & drop.

Next, apply a filter for Release 1 using the filter above the workflow diagram. This provides an end-to-end view of exactly which parts of the workflow are planned for the first iteration. This powerful view not only helps you understand the impact of your prioritizations but also serves as a valuable tool for discussing priorities with stakeholders to ensure everyone is on the same page.

Wrap up

This concludes the seven steps of Event Modeling. You have now built a system model using proven methods. From here, your team can start implementing each Read Model and each Write Model based on priority.

You can also choose to complete the Domain Model by specifying all Entities (see the guide on DDD linked at the bottom of this page). After that, you can let AI generate a code skeleton for you, as described in the article "AI Generated Code," also linked in the footer.