From Sticky Notes to Pull Requests: How Domain Models Become ADRs

You ran an event storming session. The board is covered in sticky notes — domain events in orange, commands in blue, actors across the top, policies connecting the flows. Everyone in the room sees the system clearly. Then the meeting ends, and the board sits there. A week later, nobody looks at it. A month later, nobody remembers what half the decisions meant.

This is the dirty secret of domain modeling: the model is only useful if it travels with the code. A whiteboard that nobody references is decoration. An Architectural Decision Record in your repository is architecture.

Vibe modeling is the practice of visually exploring domain events, system boundaries, and user flows with AI before writing code. The model you build during a vibe modeling session isn’t meant to sit on a whiteboard — it’s meant to become an artifact that travels with your code.

The gap between modeling and building

Most teams treat domain modeling and development as separate activities. You model on Monday, code on Tuesday, and by Wednesday the model is already out of date. The events you discovered during storming never make it into the codebase. The bounded contexts you identified live in someone’s notes, not in your folder structure.

The problem isn’t discipline — it’s tooling. Whiteboard tools are designed for exploration, not export. They give you a beautiful canvas and no path to your repository. So the model stays visual and the code stays unstructured.

What an ADR captures

An Architectural Decision Record is a short document that answers four questions:

1. What did we decide? “The billing context owns subscription lifecycle. Notifications are triggered by domain events, not direct calls.”
2. Why did we decide it? “During event storming, we discovered that billing and notifications had an implicit coupling through the User model. Separating them reduces change risk.”
3. What did we consider? “We considered keeping a single User service, but the event flow showed five different responsibilities converging on one object.”
4. What are the consequences? “Notification logic must subscribe to billing events. Adding a new notification channel doesn’t require changes to the billing context.”

Notice what happened: every answer references what you discovered during modeling. The ADR isn’t abstract architecture — it’s the translation of your visual exploration into a decision that lives next to the code.

From board to PR

Here’s the workflow that makes this concrete:

Model first. Run an event storming session — even a solo one. Map the domain events, identify the bounded contexts, trace the flows. This is vibe modeling — exploration, not planning.

Export the structure. Take the bounded contexts and their events and turn them into a structured summary. Which contexts exist? What events flow between them? What commands trigger those events?

Write the ADR. For each significant boundary or decision, write a short ADR. Use the model as evidence. “We identified these events clustering around billing. We’re creating a billing context with these responsibilities.”

Open the PR. The ADR goes into your repo — typically in a docs/decisions/ folder. The PR description references the domain model. Reviewers can see not just what you decided, but the visual exploration that led to the decision.

A domain model that becomes a Pull Request isn’t documentation — it’s a decision with an audit trail. It’s the difference between “we talked about it” and “we committed to it.”

Why this matters for AI-assisted development

When you vibe code with AI, the tool makes decisions for you constantly. Where to put the subscription logic. How to structure the database. Whether notifications should be synchronous or event-driven. Those decisions are invisible — buried in generated code that you might not fully read.

An ADR makes those decisions explicit. When the AI generates a billing module, you can compare it against your ADR: “Does this match the bounded context we defined? Does it respect the boundaries we drew?” The model becomes a review checklist.

And when you need to change something six months later, the ADR tells you why things are the way they are. Not “because the AI generated it this way,” but “because we discovered during event storming that billing and identity need separate models.”

---

The best domain models don’t live on whiteboards. They live in Pull Requests, as Architectural Decision Records that connect visual exploration to committed decisions. The sticky notes are how you think. The ADR is how you remember. Put your domain on the board and see what emerges.