Crack the Domain with Event Storming By Vivek
Download as PPTX, PDF0 likes42 views
The idea behind this session is to equip you with a practical, collaborative method to deeply understand your domain — not just from a technical perspective, but through a lens that aligns with how the business actually works. By the end, you’ll walk away with a new mindset and tools you can take back to your team.
Ad
More Related Content
Similar to Crack the Domain with Event Storming By Vivek (20)
Recently uploaded (20)
Ad
Crack the Domain with Event Storming By Vivek
- 1. Crack the Domain with Event Storming 25 April 2025 | 06:00 PM IST By Vivek Srivastava
- 2. Meet Your Speaker Vivek Srivastava, Solution Architect at Data Axle 🚀 12+ years in engineering and cloud architecture 🛠 Specializes in Python, AWS, EKS, Terraform, and Microservices 🧠 Passionate about building resilient, scalable systems 📍 Gurgaon, India 🔗 LinkedIn: linkedin.com/in/vivek-at-work 🔗 GitHub: github.com/vivek-at-work
- 3. Agenda What do we mean by "Domain"? Problems With Domain Understanding What is Event Storming? Key Concepts & Terminologies Hands-On Activity Real-World Applications Q&A
- 4. What do we mean by "Domain"? It’s what your application is about Knowledge Activity Rule Interaction s
- 5. Examples Industry/System Domain Description 📦 E-Commerce Platform "Browsing, cart management, order placement, payment, shipping, and returns." 🚕 Ride-Hailing App "Booking rides, matching drivers, tracking trips, pricing, and trip completion." 🎓 EdTech Platform "Enrolling students, scheduling classes, delivering content, and tracking progress." 🏥 Healthcare System "Patient registration, appointment booking, diagnosis tracking, and prescription flow." 🎬 Streaming Service "Content recommendation, subscription plans, viewing history, and billing." 💳 Fintech App "Transferring funds, validating transactions, calculating interest, fraud detection." 🧾 Invoicing SaaS "Creating invoices, tracking payments, sending reminders, reconciling balances."
- 6. 🚨 Problems With Domain Understandin g Domain Knowledge is Fragmented In many orgs, this domain knowledge lives in: 1. Scattered Notion pages, 2. Tribal knowledge 3. Stale documentation 4. Or worse, someone’s head. As systems scale, this gets dangerous. Architecture decisions made in one room may contradict business logic discussed in another.
- 7. Traditional Modelling Falls Short Traditional Requirement docs or flowcharts are: • Too slow • Too abstract • Usually don’t survive first contact with actual implementation.
- 8. Domain Event A Domain Event is something that happens in your business domain that the system needs to record, respond to, or build logic around. Think of it like a fact: • It happened. • It matters. • It often triggers something else.
- 9. Real-World Examples From a few different domains: • 📦 OrderPlaced – Someone bought something. • 💳 PaymentReceived – A transaction succeeded. • 👤 UserRegistered – A new user created an account. • 🔄 SubscriptionRenewed – A license extended. • 🧯 IncidentReported – A support ticket logged. • 🛒 CartAbandoned – Useful for retention or re-marketing. • You’re not inventing these. You’re just writing down what already happens in your system from a business POV.
- 10. Not All Events Are Domain Events ⚠️A click on a button is not a Domain Event. ⚠️A log entry is not a Domain Event. 👉 Ask yourself: "Would the business care if this didn’t happen?" If yes, then it’s probably a Domain Event.
- 11. Key Properties of a Domain Event: It’s in the past tense – It already happened (e.g., UserCreated, not CreateUser). It’s meaningful to the business – Not just “button clicked,” but “OrderPlaced.” It might trigger other things – Events are often the first link in a chain.
- 12. Why Event-Driven Mindset User clicks "Place Order" OrderService calls RestaurantService Waits for confirmation Then calls DeliveryAssignmentService Then sends ETA via NotificationService Traditional Thinking (Imperative)
- 13. Event-Driven Mindset Event-Driven Thinking (Reactive) Order Placed RestaurantServic e listens → Confirms or rejects Delivery Service listens Assigns → partner Notification Service listens → Sends SMS with ETA LoyaltyService listens Adds → points
- 21. What is Event Storming? Event Storming is a Visual and Collaborative Technique for exploring domains by identifying key domain events—the things that happen in your system that matter to the business. It was introduced by Alberto Brandolini around 2013, and it flipped traditional modelling on its head by saying: “Let’s not start with data models or screens—let’s start with business events.”
- 22. Preparation 1. Clear Objective Start with a one-liner purpose for the session: ✅ “We want to model how a subscription license is activated, amended, and billed.” ✅ “We want to understand how food order flows from placement to delivery.” 🎯 This keeps the conversation scoped and valuable.
- 23. Role Why They're Critical Product Owner / Business SME Knows business logic and edge cases Backend Engineer Knows how the logic is implemented Frontend Engineer Knows user interaction and presentation QA / Tester Knows failure points and exceptions Architect / Lead Dev Understands systems and boundaries Support / Ops (optional) Understands user pain points and gaps 2. The Right People in the Room Invite people who know what really happens in the business—not just tech leads.
- 24. 3. Known Events or Use Cases (Optional but Helpful) Prepare a short list of key domain events or flows to kickstart ideation. Examples: • For Zomato: OrderPlaced, PaymentFailed, OrderDelivered • For Genie: ListCreated, RecordTagged, AudiencePurchased • For Caldera: SubscriptionActivated, CreditsAdded, LicenseExpired • ️ 🗒️Just a seed list — the team will expand on this together.
- 25. Tools & Materials 🧱 For In-Person: • Orange, Blue, Yellow-Green, Purple, Red, Brown Sticky Notes • Markers (one per person) • Wall space or whiteboard ️ 🖥️For Remote: • Miro / MURAL / FigJam board set up • Pre-created sticky note templates with legend • Zoom/MS Teams with screen share • Optional: Timer and breakout rooms for parallel modeling
- 26. Ground Rules / Icebreaker Prompts To warm up the room and set collaboration tone: • "No wrong ideas — everything starts with curiosity." • “Speak in business terms first, not tech terms.” • “Don’t worry about what it should be, describe what it is.”
- 27. Outcome
- 28. Domain Events (“What happened?”) These are business-relevant facts that happened. Examples: • OrderPlaced • RestaurantConfirmedOrder • DeliveryPartnerAssigned • OrderDelivered • PaymentFailed 🧠 Tip: Always in past tense – it’s already happened. OrderPlace d
- 29. Commands (“What triggered it?”) These are instructions given by a user or system to make something happen. Examples: • PlaceOrder • CancelOrder • AssignDeliveryPartner • NotifyCustomer 💬 Think of these as verbs or actions a user/system requests. PlaceOrder
- 30. Policies (“What should happen automatically?”) Business rules or system logic that reacts to events and issues commands. Examples: • If OrderPlaced, then NotifyRestaurant → • If PaymentFailed, then CancelOrder → • If OrderDelivered, then CreditLoyaltyPoints → • ⚙️Policies are logic that listens to events and causes a response. NotifyResta urant
- 31. An Aggregate is a consistency boundary A cluster of domain objects (usually one root entity + related data) that ensures business rules are enforced before an action takes place. Think of it as the “decision maker” in your domain: • Should this command be allowed? • Is the current state valid for this operation? • Do we have enough information to produce an event? Order
- 32. External Systems / Boundaries (“What systems are involved?”) Used to show integrations or external boundaries. Examples: • PaymentGateway • SMSProvider • MapsAPI (for routing) • 🌐 This helps identify bounded contexts and integration points. Payment Gateway
- 33. Issues / Problems / Risks (“Where are the pain points? Added during workshops to highlight bottlenecks or unknowns. Examples: • Delay in payment confirmation • Delivery partner location not updating • Restaurant UI freezing during peak hours • ❗ These inform technical debt, product gaps, or UX problems. Delay In Payment Confirmation
- 34. Read Models / Views (“What information is shown?”) Used in extended models for UI and reporting. Examples: • OrderSummary • ActiveDeliveriesView • RestaurantDashboard 🖥 These don’t influence logic but show what the user sees. OrderSummary
- 36. Phase 1 User Requests to Book Flight Flight Booked Payment Gateway Delay In Payment Confirmation Send Delay Notification To Customer PNR Number Send Ticket To Customer Booking Summary Airline API
- 37. User Requests to Book Flight Flight Booked PNR Number Delay In Payment Confirmation Payment Gateway Booking Summary Send Notification To Customer Send Ticket To Customer Payment Confirmed Airline Service
- 38. Benefits of Event Storming Fast, Cross- functional Alignment Shared Understanding of Complex Domains Foundation for Microservices Great for Onboarding
- 39. Real-World Use Cases • Agile Product Discovery • DDD + Microservices Planning • Knowledge Transfer • CRM, Subscription Platforms, etc.
- 40. Resources for Deeper Learning • Book: 'Introducing EventStorming' • Tools: Miro, MURAL
Editor's Notes
- #1: Welcome everyone! Today, we're diving into something truly powerful — Event Storming. This isn't your usual modeling session. Event Storming helps you uncover how your systems and processes work — visually, collaboratively, and efficiently. By the end of this session, you’ll know how to run one and extract real business value from it.
- #2: I’m Vivek Srivastava I am working as Solutions Architect at Data Axle. I have 12 plus years of experience working with cross-functional teams on domain modeling, large-scale system architecture, and bridging the often-missing link between business logic and implementation.
- #12: Event Storming flips traditional modeling on its head. Instead of starting with data models or screens, we start with the events that matter to the business. It’s a group activity where developers, product managers, domain experts, and other stakeholders come together. We map out commands, events, policies, and system responses visually.