Everyone agrees on the principle: model the domain before drawing the architecture. In practice, it rarely lasts more than two sprints before the team reverts to what it knows.
This isn’t a lack of discipline. It’s a confusion of levels.
The domain model and the target architecture are not successive steps of the same exercise. They are two fundamentally different exercises — with different tools, different participants, and different objectives. Confusing them guarantees that your new architecture reproduces the constraints of the old one.
Problem space and solution space — mechanics, not philosophy
The distinction isn’t conceptual. It’s operational.
The domain model belongs to the problem space: it describes what your organization does, independent of any system. What are the real business processes? What rules govern those processes? Who owns them? This level of analysis knows nothing about database tables, microservices, or migration constraints. It only knows operational reality.
The target architecture belongs to the solution space: it describes how technical systems will serve that reality. Which services, which APIs, which patterns (CQRS, event sourcing, bounded contexts) to implement the business rules identified at the previous level?
| Domain model | Target architecture | |
|---|---|---|
| Question | What does the organization actually do? | How will technology serve that reality? |
| Level | Problem space | Solution space |
| Participants | Domain experts, product owners | Architects, tech leads |
| Tools | Event storming, context mapping | C4 diagrams, ADRs, bounded contexts |
| Constraints | None — deliberately | Budget, existing stack, team |
| Output | Ubiquitous language, bounded contexts | Service map, migration plan |
The sequence is non-negotiable. The domain model must precede the target architecture — not because it’s elegant, but because without it, your bounded contexts reflect your IT org chart, not your business reality.
What teams do instead — and why it’s rational
In practice, here’s what happens in most modernization projects.
The team starts with a domain modeling workshop. Three days of event storming, post-its everywhere, energy in the room. Then the first delivery sprint kicks off. The backlog grows. Stakeholders want demos. The CTO is caught between delivery pressure and the debt of unfinished domain modeling.
By the third sprint, the domain model quietly becomes a disguised target architecture. Bounded contexts mirror the modules of the existing ERP. The ubiquitous language gets contaminated by legacy vocabulary. You start hearing “yes but in our current system it’s structured like this” — and nobody questions that “like this.”
This behavior is rational. The CTO faces real constraints: a team that has to deliver, managers who want to see progress, a budget that doesn’t cover six months of theoretical modeling. The pressure to anchor to what exists is structurally inevitable.
The problem isn’t willingness. It’s the setup.
The symptoms of the short-circuit
When domain modeling has been short-circuited, the signs appear months later — often after go-live.
Bounded contexts mirror the org chart. If your services map exactly to your current IT teams, that’s suspicious. Bounded contexts should reflect business reality, not existing organizational boundaries.
The ubiquitous language is contaminated by legacy. Developers and domain experts talk about the same concept with different terms. Or worse: they use the same term for different concepts. That’s the sign that domain modeling stopped at the surface.
Business rules are scattered across the code. Without a formalized domain model, business rules end up in technical layers — SQL, validations in controllers, conditions in event handlers. Impossible to maintain, impossible to explain to domain experts.
The migration reproduces the existing system. Module by module, table by table, the new system copies the old one with a new stack. New technology, same constraints.
I’ve seen this pattern in projects worth €1.5M, delivered on time, where users were frustrated from day one of go-live. That wasn’t a delivery failure. It was a design failure.
How to make it survive contact with delivery
Domain modeling dies under delivery pressure because it’s positioned as a phase — with a start, an end, and a handover. That’s the wrong model.
Separate the two horizons in time. Domain modeling must precede delivery by at least four to six weeks. If the event storming workshop starts at the same time as the first sprint, it has no chance. Delivery pressure always consumes abstraction.
Protect domain modeling from contingency. Someone must be responsible for maintaining the integrity of the domain model throughout the project — regardless of sprint pressure. That role isn’t the tech lead’s who is deep in delivery. It’s typically an architect or external consultant who isn’t caught in day-to-day execution.
Validate with domain experts, not developers. The ubiquitous language is built with those who live the business processes, not those who will code them. If your event storming only has developers in the room, you’re modeling your system model, not your domain model.
Test against real edge cases. Before moving to the target architecture, stress-test the domain model against your most complex situations — exceptions, edge cases, rules that seem contradictory. That’s where gaps appear, not in the nominal flows.
Document the “why” of each bounded context. Every bounded context should be explainable in one business sentence, without DDD jargon. If you can’t explain it to a business director, you’ve modeled a technical artifact, not a business concept.
So, concretely
If you’re CTO of an ongoing modernization project, one direct question: who on your team is responsible for the integrity of the domain model today?
If the answer is “nobody” or “everyone” — the domain model is already dissolving into the target architecture.
The problem isn’t that your team doesn’t know how to do DDD. It’s that the setup doesn’t protect domain modeling from delivery pressure. The tech lead supervising sprints can’t simultaneously maintain the analytical distance needed to keep the problem space intact.
That’s precisely where external involvement has value — not to replace the team, but to hold the role that internal structure can’t hold: maintaining the integrity of the domain model while delivery moves forward.
That’s the first thing I look at in an Architecture Assessment: does the domain model exist independently of the current system, or is it already a projection of what exists.
If you’re a CEO rather than a CTO and you’re preparing a modernization project, this article covers the same dynamic from the business side →