Event Storming на практике: как моделировать сложные системы #71

SUMMARY

In this experimental podcast episode, host Kirill Makevnin and guest Eugene Lukyanov, a DDD architect, conduct a live Event Storming session to model a Telegram service for content creators, inspired by VidIQ, exploring events, aggregates, and system boundaries without prior preparation.

STATEMENTS

• Event Storming is the simplest tool in DDD for exploring and modeling domain knowledge, often used collaboratively with domain experts.
• The approach emphasizes simplicity, using informal notations like sticky notes that resemble code structures.
• It works well for existing domains like accounting but also for inventing new ones, such as early internet advertising concepts.
• Event Storming sessions can precede formal requirements gathering, allowing for cycles where user stories are mapped against domain realities.
• Many initial requirements from user stories turn out to be fantasies and get discarded after domain exploration.
• Unlike use cases, Event Storming is accessible to non-technical people, avoiding complex documentation.
• It fosters a ubiquitous language in DDD, extracting terms from experts and loading them into developers' minds.
• In startups, solo founders may skip formal modeling since they embody all roles, but it prevents illusions of understanding without expert input.
• Direct interaction with domain experts yields better results than relying on system analysts, who may prioritize speed over depth.
• Event Storming reveals that changing system states is the primary source of complexity in any system.
• The podcast models a Telegram service for content creators, helping with ideas, trends, and recommendations like VidIQ for YouTube.
• The service targets individual users, providing full value without needing a marketplace or network effects.
• Core features include registration, channel addition, trend analysis, and daily idea generation using AI.
• Recommendations should balance hot topics, competitor analysis, and evergreen content for sustained growth.
• Parsing Telegram channels involves gray-area techniques due to API limitations, focusing on public data.
• The model starts with domain events in past tense, like "user registered," to focus on completed facts.
• Events change system states, and business terminology is preferred over technical details.
• Aggregates represent clusters of related entities that maintain consistency, like a user owning channels.
• Invariants are rules that must hold throughout an aggregate's lifecycle, such as unique emails.
• External systems like Telegram parsers are integrated via events, handling notifications and data pulls.
• Bounded contexts define system boundaries, preventing overcomplication in early stages.
• MVP focuses on core value: providing daily recommendations without over-engineering features like auto-posting.
• Trends are derived from outperforming posts in similar channels, using engagement metrics.
• Categories or tags for channels should be flexible, possibly multiple, to handle evolving content.
• Ownership verification uses OAuth-like mechanisms, but for MVP, it may be skipped to reduce friction.
• Automatic rules trigger actions like categorizing new channels or recalculating trends daily.
• The process highlights that 90% of projects fail before coding due to poor domain understanding.
• Startups differ from enterprises in design: rapid prototyping versus rigorous modeling.
• VidIQ's success lies in analytics like daily ideas, leaderboards, and competitor insights, adaptable to Telegram.
• Parsing limitations mean starting with current posts, not historical data, for new services.
• Changing ownership requires re-verification to maintain security, though MVP may ignore transfers.
• Subscriptions and plans introduce business logic, limiting features like channel counts.
• Event Storming acts as a system map, evolving with changes rather than becoming obsolete.
• AI integration for recommendations starts simple: prompt-based generation tied to trends.
• The session uncovers hotspots like parsing mechanics, marked for further research.

IDEAS

• Event Storming's sticky-note output mirrors code, making abstract DDD concepts tangible for developers.
• Inventing domains without precedents, like early online ads, reveals hidden assumptions through iterative modeling.
• Ubiquitous language emerges organically, bridging expert jargon and code without lengthy translations.
• Solo startup founders risk self-illusion by skipping modeling, assuming domain knowledge without validation.
• Direct expert talks bypass analyst layers, uncovering nuances like debit-credit confusions in accounting.
• System state changes, not features, drive most complexity, forcing explicit event modeling.
• A Telegram VidIQ analog empowers creators with AI-driven ideas, avoiding marketplace dependencies for B2C simplicity.
• NLP-like mirroring of successful creators' patterns (posting times, frequencies) boosts non-content mechanics.
• Hot trends from Wordstat-like tools show query dynamics but fail for indirect searches like AI prompts.
• Competitors aren't always rivals; analyzing growing channels reveals adoptable patterns without direct rivalry.
• MVP omits ownership verification to minimize drop-off, as public data suffices for analytics.
• Categories evolve into tags for multi-thematic channels, preventing rigid assumptions about content focus.
• Parsing Telegram requires gray hacks, starting with new posts only, due to API gaps.
• Trends prioritize relative performance (e.g., 100x views) over absolute, highlighting outliers.
• Daily ideas create rhythmic engagement, unlike constant streams, fostering habit formation.
• Ownership as a separate aggregate (ChannelOwnership) handles transfers without disrupting analytics.
• Push vs. pull models for data: ideal webhooks, but polling suits Telegram's constraints.
• Invariants like unique channel ownership prevent duplicates, enforced at aggregate boundaries.
• Automatic jobs for daily trend recalculations ensure freshness without user triggers.
• Bounded contexts start large in MVPs, easier to split than merge post-implementation.
• AI prompts for recommendations mix trends and evergreen topics, refined via user feedback loops.
• Post editing triggers re-categorization, but MVP ignores to simplify state management.
• Engagement metrics (shares, reactions) replace views for Telegram's non-viral nature.
• Generative AI tools like ChatGPT accelerate modeling but miss nuanced, organization-specific jargon.
• Code generation from Event Storming yields small, reviewable chunks, reducing context overload.
• State immutability snapshots (e.g., frozen post metrics) simplify analysis over live changes.
• Hotspots like parsing mechanics flag research needs, preventing premature implementation.

INSIGHTS

• Event Storming demystifies DDD by turning philosophical concepts into collaborative, visual prototypes that evolve with feedback.
• Skipping domain modeling in startups creates illusions of understanding, as unvalidated assumptions lead to misaligned products.
• State changes amplify system complexity exponentially, making event-driven modeling essential for tracing impacts.
• Ubiquitous language isn't just terminology; it's a shared mental model that reduces miscommunication costs across teams.
• MVP boundaries prioritize core value delivery, deferring verification frictions that inflate drop-off rates.
• AI enhances but doesn't replace human nuance in domain invention, where gray areas like parsing demand practical hacks.
• Trends as relative outliers reveal viral potential early, adapting YouTube metrics to Telegram's subscription model.
• Aggregates enforce consistency locally, allowing scalable systems without global transaction nightmares.
• Automatic rules decouple user actions from backend jobs, enabling efficient, always-on processing.
• Large initial bounded contexts facilitate rapid iteration, avoiding premature microservice fragmentation.
• Feedback loops via alpha tests refine AI recommendations faster than isolated design.
• Invariants safeguard business rules, turning potential errors into enforced opportunities.
• Polling over push suits constrained APIs, trading efficiency for reliability in data ingestion.
• Post-metric evolution (e.g., delayed virality) necessitates ongoing analysis, not one-time snapshots.
• Code from modeled events is modular and reviewable, leveraging AI for acceleration without losing control.

QUOTES

• "Event Storming is the simplest tool for exploring and modeling domain knowledge."
• "Sticky notes end up resembling code outlines, making it intuitive for developers."
• "Many user stories are fantasies; half get discarded after domain exploration."
• "It extracts language from experts' heads and loads it into developers' minds."
• "Direct expert interaction beats analysts who rush requirements without depth."
• "Changing state is the main source of pain in any system."
• "90% of projects break before code due to poor domain understanding."
• "Startups prototype fast; enterprises model rigorously—approaches differ radically."
• "Recommendations are the hardest part; they require complex mechanics."
• "Write about what works: demand, trends, avoiding illusions."
• "Learn from YouTube and VidIQ: trends, competitors, daily ideas."
• "Aggregates, events, invariants without academic pain."
• "Ownership, security, rights transfer add real complexity."
• "Subscriptions, plans introduce business limits."
• "Parsing Telegram: reality, gray zones, platform constraints."
• "Event Storming maps the entire system holistically."
• "Use it in practice to avoid coding illusions."
• "MVP ends overcomplication; focus on activation funnel."
• "AI for recommendations starts simple, evolves with data."
• "State changes demand explicit event tracing."

HABITS

• Conduct Event Storming sessions collaboratively with domain experts early in projects.
• Use past-tense events to focus on completed facts, avoiding psychological discomfort of unfinished tasks.
• Start modeling from end goals, working backward to identify essential prerequisites.
• Incorporate automatic jobs for daily recalculations like trends to maintain freshness.
• Defer complex verifications like ownership in MVPs to reduce user friction.
• Analyze competitors by adding them manually initially, refining with automation later.
• Prompt AI for category suggestions, iterating based on real channel data.
• Maintain a living Event Storming map, updating before any code changes.
• Prioritize relative performance metrics over absolutes for trend detection.
• Seek direct user feedback in alpha tests to tune recommendation algorithms quickly.
• Use polling for data pulls in constrained environments like Telegram APIs.
• Enforce invariants at aggregate boundaries to ensure consistency without global locks.
• Begin with large bounded contexts, splitting only after clear boundaries emerge.
• Generate code in small, event-based chunks for easier reviews.
• Mirror successful creators' patterns, like posting frequency, for mechanical gains.
• Archive unused categories to keep taxonomies clean and navigable.
• Integrate external systems via events, notifying on additions like new channels.
• Formulate goals in accomplished form for clearer path visualization.
• Avoid over-documentation; let visuals like sticky notes guide implementation.
• Cycle between user stories and domain models to validate assumptions.

FACTS

• Event Storming originated as a DDD practice around 6-7 years ago, popularized for its simplicity.
• 90% of software projects fail before coding due to inadequate domain comprehension.
• VidIQ analyzes YouTube trends, competitors, and ideas, serving millions of creators.
• Telegram lacks official APIs for historical post access, forcing gray-area parsing.
• Wordstat data lags by about a month, useful for rising trends but not real-time.
• AI queries like "искусственный интеллект" show massive search volumes, but indirect uses skew results.
• Tailwind CSS creator's revenue dropped 80% due to AI-generated alternatives.
• YouTube allows non-sequential content; Telegram demands thematic consistency to retain subscribers.
• Engagement in Telegram relies on shares and reactions, as views don't viralize easily.
• Bounded contexts in DDD prevent monoliths, but over-splitting leads to integration hell.
• Ownership verification in services like TGStat uses OAuth-like logins for security.
• Banks automatically revoke access on ownership changes, per regulatory mandates.
• Extreme Programming advocated on-site users since the 1990s for better alignment.
• DDD emphasizes aggregates for transactional consistency within boundaries.
• AI tools like ChatGPT excel at structuring hierarchies but miss proprietary jargon.
• Polling thousands of channels risks rate limits and bans in Telegram.
• Post editing in channels can alter metrics, requiring re-analysis.
• Startups like Hexlet evolved from 3-day prototypes over 12 years.
• 12,500 organic Telegram subscribers highlight non-monetized influence potential.
• Invariants like unique emails prevent duplicates across user bases.

REFERENCES

• Event Storming (DDD practice, book by Alberto Brandolini).
• Domain-Driven Design (DDD philosophy, book by Eric Evans).
• VidIQ (YouTube analytics tool for trends and ideas).
• TGStat (Telegram analytics service with bot integration).
• Wordstat (Yandex tool for search query trends).
• ChatGPT (AI for categorization, recommendations, and modeling).
• Tailwind CSS (framework impacted by AI, creator's revenue story).
• Google OAuth (for user registration).
• Stripe (payment integration for subscriptions).
• Hexlet (education platform, startup example).
• Extreme Programming (1990s methodology by Kent Beck).
• BPMN (formal notation contrasted with Event Storming's informality).
• User Story Mapping (pre-Event Storming technique mentioned).
• GitHub (for open-source parsing tools).
• Twitter API (for trend pulling in AI prompts).
• Avito (example of parsed services for job searches).
• Cake (authentication library for generic user contexts).
• One language programming (ubiquitous language example in accounting).
• Russian Java classes (using native terms for domain accuracy).
• Cursor (AI code generation tool).

HOW TO APPLY

• Begin with a clear end goal, like providing daily recommendations, to anchor the modeling.
• Gather domain experts or simulate via brainstorming for initial event brainstorming.
• List all potential domain events in past tense, focusing on state-changing facts.
• Arrange events chronologically on a canvas to visualize the core user flow.
• Identify commands triggering events, such as "register user" leading to "user registered."
• Define aggregates as consistency boundaries, like User owning Channels.
• Add invariants as rules, ensuring uniqueness like one owner per channel.
• Mark hotspots with questions for unresolved mechanics, like parsing APIs.
• Incorporate external systems via events, notifying on integrations like channel additions.
• Draw automatic rules for background processes, such as daily trend jobs.
• Cycle back to user stories, discarding mismatches with domain realities.
• Assign roles to events, distinguishing users, admins, and systems.
• Visualize data flows, including reading models for UI without state changes.
• Test the map by tracing paths from registration to value delivery.
• Refine categories using AI prompts for hierarchical taxonomies.
• Simulate ownership verification flows, deferring if MVP friction is high.
• Plan polling schedules for data pulls in API-limited environments.
• Update the map iteratively before coding any changes.
• Generate small code chunks from events for review and implementation.
• Conduct alpha tests with users to validate and tune recommendations.
• Split into bounded contexts only after MVP clarifies boundaries.
• Document visuals as living artifacts, not static specs.

ONE-SENTENCE TAKEAWAY

Event Storming practically models complex systems like Telegram creator tools, revealing domain insights before coding.

RECOMMENDATIONS

• Start Event Storming sessions unprepared to mimic real discovery.
• Prioritize events over commands to focus on business outcomes.
• Use past tense for events to enforce completion mindset.
• Collaborate with non-technical experts for authentic domain language.
• Defer ownership verification in MVPs to boost activation rates.
• Analyze trends via relative performance, not absolute views.
• Leverage AI for initial category extraction from channel descriptions.
• Implement polling for Telegram data due to API constraints.
• Enforce invariants at aggregates to maintain consistency.
• Keep bounded contexts broad initially for easier refactoring.
• Automate daily jobs for trend and recommendation refreshes.
• Mirror VidIQ's daily ideas for rhythmic user engagement.
• Skip historical parsing; focus on new posts for quick launches.
• Use tags over rigid categories for multi-thematic channels.
• Integrate feedback loops early via alpha user chats.
• Model state changes explicitly to anticipate complexity.
• Generate code from event maps in modular pieces.
• Avoid over-documentation; let visuals drive implementation.
• Trace full user flows including reading models for UI clarity.
• Evolve the map as a living tool with every project change.

MEMO

In a lively, unscripted podcast episode of "Organized Programming," host Kirill Makevnin, a seasoned developer and entrepreneur, teams up with Eugene Lukyanov, a domain-driven design (DDD) architect, to dive into Event Storming—a hands-on technique for modeling complex software systems. Without prior preparation, they tackle a real-world idea: a Telegram service for content creators, akin to YouTube's VidIQ, which would analyze channels, spot trends, and generate daily content ideas using AI. The session unfolds on a shared digital canvas, transforming abstract DDD philosophy into vivid sticky-note events, revealing how 90% of projects falter not from code, but from fuzzy domain understanding.

As they sketch the user journey—from registration to personalized recommendations—Makevnin and Lukyanov emphasize Event Storming's simplicity. Events like "user registered" or "channel added" are plotted in past tense, forcing focus on completed facts rather than vague intentions. This mirrors goal-setting techniques, where accomplished phrasing clarifies paths forward. They debate startup versus enterprise pitfalls: solo founders often code illusions of clarity, while big teams drown in analyst intermediaries. Direct expert chats, Lukyanov insists, unearth nuances—like confusing debits in accounting—that specs miss, echoing Extreme Programming's call for on-site users since the 1990s.

The model's core pulses around aggregates, those consistency clusters like a "user" owning "channels," enforced by invariants such as unique emails. Hotspots emerge: Telegram's API gaps demand gray parsing for public posts, starting with fresh content to sidestep historical bans. Ownership verification, inspired by TGStat's OAuth logins, gets deferred in the MVP to cut drop-off, as analytics thrive on open data alone. Automatic rules kick in—daily jobs pulling trends via polling, since webhooks are pipe dreams here—highlighting state changes as complexity's root.

Trends take shape as relative outliers: posts outperforming a channel's baseline by 100x, measured in shares and reactions, not viral views like YouTube. Recommendations blend AI prompts with this data—mixing hot queries from tools like Wordstat and evergreen topics—for rhythmic daily delivery, fostering creator habits. Multi-tags handle evolving themes, avoiding rigid categories that ignore channels' shifts, say, toward AI hype. External integrations, like notifying a Telegram parser, surface via events, underscoring the technique's map-like power.

Subtleties arise in ownership transfers: a new claim revokes old links, but MVPs ignore re-verifications to simplify. Subscriptions layer business logic later, limiting channels per plan, much like fine-print bank rules. The duo warns against microservice frenzy early—start with fat bounded contexts, easier to trim than fuse. AI like ChatGPT shines for hierarchies but falters on jargon; human "leather bags," as Lukyanov quips, prune half-baked ideas.

Ultimately, this live storming exposes Event Storming's edge: a living blueprint that anticipates pains, from post edits triggering re-analysis to engagement's slow burn. It demystifies DDD for startups, proving visual collaboration trumps solitary coding. Makevnin, reflecting on his Hexlet origins—a three-day hack turned 12-year evolution—urges viewers: model before building, or risk illusions. As they wrap, the canvas hums with potential, a testament to why 90% fail pre-code: domains demand dialogue, not dictation.