Two ways to learn Event Modeling with Nebulit: a private workshop run on your team's real system, or a public cohort workshop with fixed dates and a seat price.
Both delivered by Nebulit.
Both cover the same core method - the difference is who's in the room and what you're modeling.
A dedicated, facilitator-led engagement for your team, modeling your real system. On-site or remote, scoped and priced per engagement.
Open enrollment, fixed dates, remote via Microsoft Teams. Learn alongside people from other teams and companies, priced per seat.
Two days. Your real system. A model your team can actually build from - not a slide deck nobody opens again, and not just a model on the wall that nobody touches again.
A paid, facilitator-led engagement delivered by Nebulit - book a call to talk scope and pricing.
Why: the structure isn't arbitrary - each step exists to catch a specific kind of gap before it becomes a production incident. Skipping one just moves the problem downstream.
Six steps, run in order, over two days. Expand a step to see its goal and how a facilitator actually runs it in the room.
Hand everyone orange stickies and ask a simple question: "What happened?" No structure yet, no order - just get every event anyone can think of onto the wall. Quantity over precision here; you'll sequence and merge duplicates in the next step.
Take the pile of events from step 1 and arrange them in a rough left-to-right timeline. Ask the two anchor questions every time: "What's the first event?" and "What's the last event?" Once you have a beginning and an end, the middle fills in naturally.
Sketch a simple wireframe screen above the events a user would actually see at that point in the flow. This is where business and engineering stop talking past each other - a screen makes the abstract event timeline concrete for everyone in the room.
Add Commands below the screens and Read Models above them, and draw the arrows: Screen reads Read Model, Screen sends Command, Command produces Event, Event feeds Read Model. This step exposes every place a screen needs data that no event currently produces - the most valuable gaps to find before anyone writes code.
Draw horizontal lanes for each team or system, and slot every event into the lane of whoever owns that data. Ownership questions that were implicit before - "wait, who's actually responsible for this?" - become impossible to avoid once the lanes are drawn.
For each slice, write Given-When-Then scenarios - the happy path first, then the error cases. Ask three times: "Is there any rule we didn't cover?" Business rules that used to be tribal knowledge get written down as literal test cases, ready to hand to a developer or an AI agent.
Want the full reference? The cheat sheet covers the 4 patterns, the 4 anti-patterns to watch for, and all 30 rules in one page.
Why: a model only aligns a team if the whole team helped build it. Leave any of these roles out and the workshop produces a diagram, not shared understanding.
Bring the people who actually know the domain - not just the people who usually attend meetings about it.
Stop guessing what to build. Leave with a model that tells you exactly what commands to handle, what events to emit, and what read models to maintain.
Design resilient, event-driven systems from the ground up. Use the model to draw architectural boundaries the whole team agreed on, not ones handed down after the fact.
Translate business requirements into a specification engineering can ship from - without handoff friction, ambiguous user stories, or last-minute scope surprises.
You know the rules nobody wrote down. A workshop is where they finally get captured - as scenarios an engineer or an AI agent can build against.
Why: a workshop that ends with a whiteboard photo and good intentions changes nothing. One that ends with a board your team keeps using changes how the next ten sprints get planned.
Ambiguities and missing edge cases get found and resolved in the room - not three sprints later in a bug report.
Business and engineering leave with the exact same picture of what the system does - not two versions that quietly diverge.
A model detailed enough for your team - or an AI agent - to build directly from, slice by slice.
See the true scope of the domain laid out on the wall, instead of guessing at it in a planning meeting.
Slices sized and sequenced directly from the model, ready to plan into sprints without a separate estimation session.
Hotspots and open questions get documented on the board - not discovered for the first time in production.
Documentation that stays accurate because your team keeps building from it - not a one-off slide deck nobody opens again.
Why: knowing the shape of the two days up front makes it easier to block the right calendars and get the right people in the room.
Every private engagement is tailored to the domain, but the structure of the two days is consistent. Public cohort workshops follow their own fixed schedule - see below.
Runs 09:00-17:00 on-site, with a 30-60 minute lunch and a break at least every 90 minutes. Best run with 6-8 people: your engineering team plus the business domain expert(s) who know the system.
Enough time to go from a blank wall to a validated, sprint-ready model of a real slice of your system - without dragging the exhaustion out over a week of half-days.
Run it in your office with a physical wall of stickies, or fully remote on a shared digital board. Same six steps, same outcome either way.
An experienced facilitator keeps the room on track - parking side discussions, catching anti-patterns early, and asking the questions that surface hidden rules.
Why: not every team can block two days for a private engagement right away. Public cohorts run on fixed dates, remote, priced per seat - a lower-commitment way in.
Open enrollment, small cohorts, remote via Microsoft Teams. Book a seat directly - no call required.
Applying Event Modeling successfully in a team: modeling techniques, documenting business rules, facilitating workshops, and maintaining models. Includes the Event Modeling Toolkit.
From requirements to slice-based architecture: Event Sourcing principles, CQRS, hands-on coding and testing, real-world examples. Includes a code repository, Miro license, and book.
See the full, up-to-date schedule and pricing at nebulit.de/workshops.
Book a private workshop for your team, grab a seat in the next public cohort, or read the cheat sheet first to see exactly what a session looks like.