Using LLMs for Domain Exploration

Several weeks back, I got to continue a conversation with Eric Evans – one that we started at DDDEU 2025 in Antwerp.

Disclaimer: Eric Evans kindly engaged in this conversation, but has no affiliation with Envivo and offers no endorsement – expressed or implied – of our approach or technology.

If you follow Eric’s more recent work, you’ll know he’s been exploring the role of Large Language Models within the DDD space. This lined up neatly with some of the thinking we’ve been doing – particularly around how LLMs can support the early, messy stages of domain discovery, and how we move from there into something more concrete.

Most of what you see online is about using LLMs to write or refactor code (and ‘vibe-coding‘). While that’s an impressive challenge, it hasn’t held much appeal for me. We’ve seen how often that becomes an exercise in frustration – trying to push a statistical model into solving for precision and correctness. IMO, it’s not where LLMs shine.

The more interesting question (the one that brought Eric and I together) is:
“Can LLMs help with domain discovery? And if so, how well do they handle complexity?”

Domain exploration is central to the work we do: teasing apart business concepts, understanding the boundaries, and gradually forming a domain model that reflects the real shape of the problem. Our usual approach is to work toward a structured object model that expresses those ideas clearly.

We ran a live session, and “Energy Trading” was picked as the domain of interest, mostly because “it’s complicated” (Eric’s choice, not mine!). Using our PRISM AI assistant, we explored how far it could get with minimal prompting, and discover where explicit guidance was needed. Through immediate interactive prototypes, we could quickly examine the domain model designs, and revise them as the conversation evolved.

One thing we explored was how the LLM handled different types, particularly around derivatives. Initially, it presented a few core terms (Swaps, Options, Bilateral Agreements) and created a flattened structure with common fields shared across all.

For a first pass, it was entirely functional, but it wasn’t a particularly clear design, where unused fields are simply left blank. From experience, I could see that this design would be open to data consistency errors.

The turning point came when we nudged the model to think more like a domain expert: not just to define terms, but to explore relationships and intent. That led to a more meaningful set of distinctions.

In particular, we looked at the difference between structural relationships and taxonomies: something that’s often blurred in early modelling. But when you treat taxonomies as a first-class concern, the design starts to unfold.

We saw a clear separation emerge between:

• Subtypes that share the same structure but differ in role or semantics (which we’d normally treat as enumerations), and
• Subtypes that require distinct properties or behaviours (which align better with polymorphic types or interfaces).

This isn’t a new idea, of course. But it was encouraging to see the LLM respond well when nudged in the right direction, and even proposing alternatives that would make us pause and rethink.

Getting taxonomies right can make your domain model far more accurate. However, it does depend on context, and on how the terms are actually used. In some cases, the same term can have different taxonomies!

But that’s another conversation, which I’ll save for another time.

Interlude: On Hallucinations

One of the side conversations we had was about hallucinations: something many people see as a fundamental flaw in LLMs.

Personally, I’ve never found hallucinations to be a blocker. If anything, they often point to gaps in the way the prompt or problem has been framed. If the output feels wrong, the fix is the same as in any modelling activity: rethink the input and try again.

The underlying LLM isn’t broken; the interface is just different from what most people are used to. We’ve spent decades treating computers like deterministic machines. An LLM doesn’t behave that way, and it can be unsettling if your expectations are still rooted in “it’s just a faster calculator.”

Simon Wardley summarised it quite nicely:

“Treat hallucinations as a feature, not a bug.”