In my previous post I talked about the fallacy of abstractions in a line of business application. In this post I'll show how we can avoid this fallacy by embracing EventModeling. We can use this technique to help us model the business processes.

Modelling business processes, that's precisely where EventModeling shines. It provides the bridge between business understanding and system design, helping us developers stay grounded in actual business processes instead of drifting into premature abstractions.

Let me try to unpack how that works.

Why EventModeling Fits So Well Here

When we developers try to "generalize" too early, it's usually because we're working from data models or class hierarchies, not from processes or user workflows. EventModeling flips that mindset:

Instead of starting with "what objects should we create," we start with "what actually happens in the business over time."

EventModeling in Action: L&H Example

Let's take the example from my previous post — premium payment collection for a Life & Health insurance policy.

Instead of creating a generic Payment abstraction, we ask:

"What business events happen in this process?"

We might get something like:

Step | Event               | View
---------------------------------------------------------
1 | PolicyIssued | Show active policy
2 | PremiumDueGenerated | Show upcoming payment
3 | CreditCardCharged | Show successful charge
4 | PaymentFailed | Show outstanding balance
5 | PaymentReceived | Show policy in good standing

Each event tells a business story that everyone — underwriters, finance, IT — can understand. There's no "generic payment" here.

If we later introduce direct debit, we'll get new business events such as:

• DirectDebitMandateCreated
• DirectDebitInitiated
• DirectDebitSettled

…and that's perfectly fine, because each payment type has a different real-world flow. We're modeling the business reality, not forcing it into a technical abstraction.

What EventModeling Prevents

1. Premature abstraction
2. Misalignment with business language
3. Hidden complexity

The Payoff

Without EventModeling we have

1. We developers create generic data models upfront
2. Abstractions hide domain differences
3. Our conversations revolve around "data types"
4. Domain experts disengage

Contrast this with with what we get with EventModeling:

1. Teams design based on real user interactions and business outcomes
2. Each flow clearly shows unique domain behavior
3. Conversations revolve around "what happens next"
4. Domain experts actively co-design the process

In the Broader L&H Context

This approach works brilliantly across the insurance lifecycle. Here are a few processes and example events:

• Underwriting: ApplicationSubmitted, RiskAssessmentRequested, MedicalReportReceived, UnderwritingDecisionMade
• Policy Administration: PolicyIssued, PremiumDueGenerated, PremiumPaid, PolicyCancelled
• Claims: ClaimSubmitted, ClaimReviewed, ClaimApproved, ClaimPaid

We get end to end visibility of how value flows — exactly what Value Stream Analysis seeks to reveal, but now made executable in our design.

🎯 In Short

EventModeling makes business processes the source of truth — not technical abstractions.

It grounds us developers in what's real and observable, while still providing a structure that can evolve into clean, scalable systems. Or put another way:

"Don't design for what might happen — model what actually happens."

Literature

Curious about EventSourcing? Then you should absolutely read Martin Dilger's fantastic book Understanding EventSourcing - Planning and Implementing scalable Systems with Eventmodeling and Eventsourcing

Originally published on LinkedIn on 15 Nov 2025: https://www.linkedin.com/pulse/eventmodeling-antidote-premature-abstraction-gabriel-n-schenker-6iuqf/