Continuous Modeling, or What Happens to the Model on Tuesday? - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

Continuous Modeling, or What Happens to the Model on Tuesday?¶

Friday afternoon. The sticky notes on the wall are the densest they've been all week. Someone has redrawn a Bounded Context for the third time, and this time everyone in the room nods. Two product managers, three engineers, a domain expert, and a coach who's been keeping the conversation honest agree: this is what the system actually is. Phones come out, photos get taken. People shake hands and say things like finally, and now we know. The room empties.

On Tuesday, someone opens a pull request that touches the boundary you spent half of Friday redrawing. The PR description doesn't mention the model. The reviewer doesn't mention the model. The model is in three Miro boards, one of which is now read-only because somebody's account got rotated, and a Confluence page that hasn't been opened in four weeks. The reviewer approves the change. The model isn't wrong yet. It's just not anywhere the work can see it. Three months later, when a new question forces you back to the wall, no one quite remembers why the boundary was where it was. Did the workshop fail? It didn't. Something else did, and almost every team we talk to keeps making the same quiet mistake.

Why Models Evaporate¶

Models don't disappear because people are lazy or undisciplined. They disappear because the artifacts they live in are structurally invisible to the work that follows them. A photo of a wall is not a model. A Miro board behind two SSO logins is not a model. A Confluence page that doesn't show up next to your code is not a model. They're souvenirs. They're proof the workshop happened. They're not where the work happens, and so the work doesn't go there.

There are three structural reasons for this, and recognizing them is the difference between blaming the team and fixing the system. The first is that the model has no home in the place where the code lives. It sits on a different platform, behind a different login, with a different review culture, often owned by a different role. Crossing that gap is friction, and friction always loses to deadlines.

The second reason is that there's no trigger that forces the model to be touched when the code is touched. You can refactor a service that sits at the heart of a Bounded Context without ever opening the artifact that defines that context. The system permits it, the tooling permits it, the review process permits it. So you do.

The third reason is that there's no review gate for the model. Pull requests gate code changes. Tests gate behavior. Linters gate style. Nothing gates the model. Drift accumulates in the only place where it isn't checked, and by the time anyone notices, the model and the code disagree, and nobody quite remembers which one was the source of truth.

The Workshop Was Never the Point¶

Workshops are catalysts, not deliverables. The output of a great workshop is clarity in the moment , the kind that lives in the heads of the people who were there and in the photos they took on the way out. Clarity that isn't tended decays into memory, and memory decays into folklore. None of that is a failure of the workshop. It's the predictable outcome of treating a workshop as the model rather than as the moment a model became visible enough to draw.

This is also why we keep coming back to the idea that strategic work in Domain-Driven Design isn't a phase you complete but a discipline you practice. Two engineers having a thirty-second conversation about whether a Command really belongs in the Order Capture context is strategic work. So is a code review that asks why a new field appeared in a Read Model that already had a stable shape. So is a Refinement where someone says, out loud, this Story crosses a boundary I'm not sure we've drawn.

Modeling is a daily habit, or it's a quarterly ritual that doesn't survive contact with reality. The question isn't whether your team values modeling. Almost every team we work with values modeling. The question is whether modeling shows up on Tuesday. That's a structural question, not a cultural one, and it has structural answers.

What Continuous Modeling Actually Looks Like¶

Continuous Modeling means three things working together. None of them is dramatic. None of them requires a new ceremony. All of them require that the model be reachable from the work the team is already doing.

The first is the Modeling Moment in Refinement. Five minutes at the start of each Refinement, before any estimation conversation, where the team asks one question: does this Story...