Event Modeling: Visible Issues and My Vision #

During my journey learning Event Modeling as part of my VibeTDD framework exploration, I discovered some issues that from my point of view limit the framework's adoption and effectiveness. After extensive research and community discussions, I decided to build a proof-of-concept that addresses these core problems.

The Problems I Discovered #

1. Canvas Layout Nightmare #

Event Modeling relies heavily on visual canvases like Miro, creating constant friction during the modeling process. The specific pain points include:

• Continuous resizing and repositioning: Every addition requires manual layout adjustments
• Cascading layout changes: Adding one element forces you to resize multiple components
• Scale anxiety: Managing hundreds of slices with multiple scenarios becomes overwhelming
• Time waste: Significant effort spent on layout management instead of actual modeling

I shared this frustration on LinkedIn, and multiple Event Modeling practitioners confirmed these concerns, including the framework's creator and experienced practitioners who acknowledged the tooling limitations.

2. Business Rules Documentation Gap #

My investigation revealed a critical architectural problem: Event Modeling has no standardized way to handle business rules. Looking at examples, I couldn't find clear documentation for rules like:

• Max 3 items in shopping cart
• Single payout limit: 30
• Total payouts can't exceed 200

This creates several problems:

• Information fragmentation: Rules must live "somewhere else" (Confluence, Jira, comments)
• Incomplete model slices: Developers need to "hunt for details" across multiple systems
• Synchronization risk: Miro boards and documentation can drift apart
• Code generation limitations: Yes, it's possible to export the model as json, but having incomplete info I mentioned above, code generation can be tricky

Even after consulting with industry experts, I found that there's no standard solution for this need.

A Simple POC to Test My Ideas #

To explore solutions to these issues, I built a simple proof-of-concept - a quick, trivial implementation to test whether a structured approach could work. This is just the beginning, a basic prototype to validate the core concepts rather than a complete tool.

1. Slices Board #

The main board shows slices in a clean, structured format without manual positioning. Each slice contains:

• Command (blue): The action being performed
• Event (orange): The result of the action
• Test Scenarios: Direct link to business logic validation

2. Structured Slice Editor #

The slice editor provides structured forms for:

• Model selection: Choose a domain object
• Operation/Status: Define the action and the slice status
• Command definition: Specify the command name and parameters
• Field management: Add fields with proper types and constraints
• Event definition: Define the resulting event and its fields
• Rules section: Add and manage business rules manually or with AI generation

3. Smart Field Connections #

The system supports dependency management between objects. When creating an order with userId and courseId, we can connect these fields to their respective events by selecting from existing events in the system.

4. Custom Type System #

Beyond basic types (String, Date, Long etc), the system supports:

• Common types like Email, CountryCode, CurrencyCode
• Custom complex types: Define reusable business objects like Price with structured fields
• Type validation: Ensure consistency across the model

5. Test Scenarios Generation #

The system generates test scenarios based on:

• Configuration parameters: Business rules with configurable limits
• Existence rules: Validation that dependent objects exist
• Business logic: Custom rules with success/failure cases
• Manual definition: Direct scenario creation through the interface

Check the full demo video: #

Key Advantages of This Approach #

No Layout Management Eliminates the constant resizing, moving, and adapting that plagues canvas-based tools.

Structured Business Rules Rules are first-class citizens with clear categorization, configuration options, and automatic test generation.

Type Safety Proper type system prevents inconsistencies and enables better code generation.

Dependency Management Manual connection of object relationships with clear visualization.

Export Capability Complete model data can be exported for code generation without external documentation hunting.

The Bigger Picture #

This proof-of-concept addresses what I call the "notepad problem" of Event Modeling. As I mentioned in the LinkedIn discussion: "I can imagine what would happen if JetBrains didn't provide a tool for Kotlin and suggested devs write code in notepad 🙂"

Event Modeling is a powerful framework, but poor tooling creates unnecessary friction that slows adoption and execution. By treating Event Modeling as structured data rather than free-form drawings, we can:

• Accelerate modeling sessions by removing layout management overhead
• Ensure completeness by requiring all necessary information upfront
• Enable automation through structured data that AI can understand easily
• Improve maintainability by keeping rules and scenarios synchronized
• Scale effectively without canvas limitations

Technical Implementation Notes #

The POC is built with modern web technologies and demonstrates:

• Form-based interfaces that are faster than drag-and-drop
• Intelligent defaults that reduce repetitive data entry
• Validation at input time rather than discovery later
• Clear separation between business rules and technical implementation
• Extensible type system for domain-specific needs

What's Next #

This proof-of-concept establishes a crucial foundation: structured slice data ready for code generation and dynamic test execution.

I've conducted a quick experiment that demonstrates the system can execute tests stored in the database rather than generating static test files. This means the test scenarios visible on the board become the source of truth, no code generation step required, no synchronization issues between specifications and tests.

The implications are significant: changes to business rules or test scenarios immediately affect test execution without any build or deployment steps. This creates a truly dynamic testing environment where the Event Model directly drives validation.