Reverse-Engineering DDD: Discovering Domains in Legacy Systems Without the Textbook

The textbook lie. Domain-Driven Design books paint a clean picture: gather domain experts in a room, run an Event Storming session, discover your bounded contexts, and design the architecture. Elegant. Logical. Almost never the reality in large enterprises.

Try applying that when you inherit a delivery and logistics domain that's been running for 30 years. It was built by multiple vendors whose contracts ended years ago. It powers millions of transactions every day, so stopping it for refactoring is not an option. Domain logic is scattered across tightly coupled monoliths, legacy databases, and vendor-owned black boxes that you can't even see inside. Nobody bothered to write it all down. The people who built it? Long gone. You run Event Storming workshops and people tell you how they think the system works. Then you look at production logs and realize it does something completely different. So where do you actually start?

This talk is about forensic DDD: treating a legacy system like an archaeological site and using production artefacts to reverse-engineer the domain model that nobody ever documented. Instead of asking "what should the domain look like?", you ask "what domain is already buried in the code, and what evidence can I find to prove it?"

The session walks through practical detective techniques for discovering domain boundaries in brownfield contexts, drawing from real work in a global delivery domain:

• API contracts as artefacts: reverse-engineering aggregates and entities from existing API shapes and request/response patterns.

• Incident clustering: finding boundary violations by analyzing where bugs and failures cluster over time.

• Log mining: treating production logs as fossilized domain events to see real flows instead of idealized ones.

• Schema archaeology: spotting accidental shared kernels by finding database tables that too many services touch.

• Transaction boundary analysis: if three tables are always updated together in the same transaction, they probably belong to one aggregate.

• Data lineage: tracking a customer order through the system to figure out which service is really the source of truth.

• Error code reverse-engineering: legacy systems encode business rules in cryptic error codes—decode them and you find implicit invariants.

• Vendor black-box interrogation: when you can't ask the people who built it, reverse-engineer their intent from API contracts, error messages, and usage patterns.

• Performance hotspot analysis: slow queries and lock contention often point to wrong aggregate boundaries or missing read models.

• Change velocity clustering: code that changes together frequently probably belongs in the same bounded context.

• Multi-market divergence detection: if Swedish and German markets behave differently in the logs, that's evidence of variant business rules or separate subdomains.

• Chain-of-custody decisions: figuring out when to wrap something in an anti-corruption layer, when to extract it, and when to leave it alone based on risk and ownership.

The talk then shows how to reconcile two versions of the domain: the one people remember (from Event Storming and conversations) and the one that's actually encoded in production. The gap between them is usually the most revealing part—it tells you where the model has drifted, where hidden business rules live, and where you need to refactor first.

Finally, there's a practical look at safe, incremental extraction: how to surgically pull one bounded context at a time out of a monolith when you can't afford downtime, using feature flags, shadow traffic, read replicas, and carefully placed anti-corruption layers to de-risk each step.

This is not a tools talk or a vendor pitch. It's about treating legacy systems not as messes to escape from, but as rich data sources for domain discovery—and learning how to design architectures that align business intent with encoded reality, even when the clean-slate chapter of the DDD book doesn't apply to your situation.

Key Takeaways

• Why Event Storming alone falls short in large brownfield systems, and how to use it as a hypothesis generator rather than gospel truth.

• A dozen practical forensic techniques for reverse-engineering domain boundaries, aggregates, and business rules from logs, schemas, APIs, and incident data.

• How to reconcile what people think the domain does with what it actually does in production, and use that gap to guide architectural decisions.

• Patterns for safely extracting bounded contexts from legacy monoliths one piece at a time, without breaking production or requiring big-bang rewrites.

• A shift in mindset: legacy systems aren't just technical debt—they're dense archives of domain knowledge, if you know how to read them.