Navigating AI-Assisted Domain-Driven Design: Opportunities, Risks, and New Ways of Working

Gien Verschatse led a session exploring Domain-Driven Design and AI.

Domain-Driven Design has long held that deep domain knowledge is the foundation of high-quality, maintainable software.

The closer solution builders are to the domain, the better the software they produce.

The rise of AI coding tools, such as Claude Code, introduces a compelling paradox: while AI dramatically reduces the effort required to implement solutions, it risks short-circuiting the learning process that makes DDD valuable in the first place.

When developers use AI to translate domain language into prompts — rather than internalising the knowledge themselves — the fundamental promise of DDD is quietly undermined.

Gien Verschatse, senior consultant at Aardling, examines that central tension, the difference between using AI to move faster versus using it as a substitute for developing domain expertise.

This session explores:

• AI-assisted DDD workflows

• Cross-functional team compositions, with AI in mind

• How junior developers risk being left behind and practical remedies

This session is relevant for software developers, team leads, or technical leads currently using AI in their software systems.

What does "AI and domain modelling in code" actually mean?

A question I often see on social media is: Is coding a solved problem now with AI? I don't think it is — and I also think it depends on your definition of both "coding" and "solved." But since we're all here as Domain-Driven Design practitioners, I wondered if that was the right question to ask in the first place. The code is just the result of a whole process that takes a lot of effort. So I wanted to focus on how we can actually use AI in each of the three phases we have: domain discovery, strategic DDD, and tactical DDD.

Without a doubt, AI is a very useful tool. It can do a lot. But at the end of it, it is still a tool — it predicts the next token, it can't really reason. I want to start from the DDD principle that most practitioners have already encountered: don't stop at your first good idea. That's a more useful frame than asking whether coding is solved.

I'm using a recycling centre as my example domain throughout, to protect client privacy. Basically, you come in, scan your ID card, go on the weight bridge, drop off waste, and eventually pay. We have two cities — Pointville and Oakland City — with different pricing rules, and different rules for business versus private customers. All of the scenarios I'll show are based on real experiences with clients.

Tactical DDD: what AI gets wrong out of the box

When I gave AI the domain knowledge written out in text and asked it to make a domain model in code, I noticed it makes the same mistakes I made when I first started programming. A lot of domain knowledge ends up inside domain services — one of the tactical patterns where you shouldn't have elaborate behaviour. You should push behaviour to entities and value objects, and have domain services only knit those together. AI fails to do that, just as I did early on.

It also doesn't understand the difference between an entity and a value object, and which situation calls for which. The domain model it produces isn't scalable — it bakes city-specific rules directly into the model. If you have 100 cities with 50 different exemption rules, you end up with all of those specifics in your code, which is not what we want.

It also doesn't respect the domain language, and it knows it isn't respecting it. It introduces new words when the right terms are already there. We talk about "visitors" most of the time; it talks about "customers." It also shows heuristic bias: it started talking about "drop-off line items," which looks very much like an order, importing structure from e-commerce into a domain where it doesn't belong.

Tactical DDD: what happens when you design upfront

That was without doing any upfront work. When you do some design upfront — even a rough model on a whiteboard — the results improve significantly. In my example, I sketched out a pricing model with a clear key structure: city, waste type, and visitor type. I separated the standard unit price calculation from the exemption rule. What I got back from AI was much more in line with how we would have programmed it ourselves. It created a fixed price calculator and a threshold calculator. There was still some tidying up to do, but the direction was right.

Upfront design of your domain model will become more important, not less, because you're not doing the detailed coding yourself anymore — the AI is doing it for you. One important difference from working with a junior developer: a junior takes feedback across projects and transfers that learning. AI cannot do that. You always start from scratch.

The biggest win is rapid iteration. You design on a whiteboard, feed that to AI, get a prototype, see what isn't working, adapt your model, feed it again. That iteration cycle used to be very time-consuming. If you don't iterate, you push a naive first model into production — and we never wanted that.

The biggest risk is that the team no longer owns the domain model. As AI does more of the coding, the knowledge of how the system works stops going into people's heads. That's a serious risk, because it makes it very difficult to adapt the system in future. We also need new ways to validate implemented domain models — we know how to validate a model on a whiteboard, but validating it once AI has implemented it is something we're still working out.

Domain discovery: the challenges of using AI

We kept hearing that teams need deep domain knowledge and shared understanding — and most of the time, we build that through domain discovery and modelling. So how can AI help with that?

We ran into three issues early on. The first was biased in its knowledge. We use an adapted version of Alberto Brandolini's event storming, and when we tried to get AI to help with domain discovery — finding assumptions, ambiguity in language, and so on — it kept giving us feedback on the technique rather than the content. Wrong post-it colour, missing policy stickers. We had to build a legend and instruct it on exactly how we were doing event storming before it could focus on the content.

The second issue was tool gaps. I had Claude create an event storm and got an SVG out of it. Then I needed to get that into Miro. Miro has its own AI now, and it could convert the output, but it lost the event storming structure, with time no longer flowing left to right. A very clunky experience. We're now experimenting with a domain-specific language as a shared format between AI input and output, to smooth that gap.

The third issue was that we weren't getting valuable information — just confirmation of things we already knew. What helped was limiting the input. Instead of feeding AI the entire event storm, we started giving it small fragments and questioning those closely. The reason: no matter how much you give it, the volume of output stays roughly the same, so it can't dive deep into anything if the input is too large. Small inputs, targeted questions, much better results.

Domain discovery: making AI actually useful

Once we started working with smaller inputs, we could get genuinely useful things out of it. We asked it to find assumptions and open questions. For the recycling centre, it flagged that we'd assumed a visitor can't be both a private and a business customer at the same time — there's no mechanism to handle that. It also asked how the yearly reset of the exemption rule actually works: is it the first of January, or a rolling calendar year from when a business customer signs up? Those were things we hadn't thought of during modelling sessions.

A few practices that help: clear the context regularly, because if you don't, AI starts pulling in earlier parts of the conversation, and the answers get less useful. And never ask leading questions — AI is designed to agree with you. If you ask it to find inconsistencies in something, it will find them, whether they're there or not. It is not a sparring partner. For that, you need colleagues who can actually think critically. But it can be your rubber duck: it helps you iterate fast on ideas and surfaces things you noted but forgot about while doing other work.

What it is genuinely good at is finding inconsistencies in language. It spotted that we were using "exemption" in a non-standard way — in common usage that would imply zero cost or exclusion, which isn't how our pricing model works. It can also find multiple words referring to the same concept: "dropping off," "delivering," and "disposing of" all describe the same action in the recycle centre domain.

We've also started enabling transcripts in remote modelling sessions and feeding parts of those to AI afterwards: what do you see here? How do you interpret this? That's been genuinely helpful for preparing for the next session.

One of the biggest risks in domain discovery is cognitive debt — a gap between the team and their understanding of the domain and the code, because they're no longer doing the discovery and programming themselves. If that gap grows too large, you also lose the ability to give AI good input, which means you stop getting valuable output. Domain expertise becomes more important, not less.

Strategic DDD: boundaries, context maps, and documentation

When it comes to strategic DDD, AI can help — but it makes beginner mistakes here too. When I asked it to design bounded contexts for the price calculation domain, it suggested a separate "price list" bounded context. But one of the core principles of boundary design is that things that change together belong together. The price list should live inside the price calculation bounded context, not outside it. AI was thinking at the aggregate level rather than the bounded context level — the same mistake I would have made years ago.

For context maps, it gets some things wrong — for example, placing the anti-corruption layer on the upstream side, when its purpose is to protect the downstream from upstream. That's a foundational mistake.

Where AI does well strategically is documentation. If you ask it to fill in a bounded context canvas once you've reached a good solution, it does it accurately. It even surfaces assumptions and open questions that came up during the design conversation. You can get that documentation in any format you want — markdown, HTML, an image. And you can update it regularly. I'm becoming more of an editor and validator of documentation than a writer of it, which saves a lot of time.

For glossaries, it's very good: give it all the terminology, ask it to explain each term with an example, and it generates a shared language repository quickly. You can also use that glossary to check for inconsistencies.

The overall pattern for strategic DDD: use AI as inspiration and for documentation, not as a design tool. It will often surface natural-looking boundaries that are worth considering, but the design itself is still yours to do.

Key takeaways

The speed gains from AI are mostly in three areas: iteration, experimentation, and documentation. You can iterate rapidly on domain models and prototypes. Because iteration is cheaper, experimentation becomes easier — you can ask "how would this look if we removed the concept of private versus business customer?" and explore quickly. For documentation, especially in strategic DDD, AI does most of the work once you've reached a good design.

Domain expertise has become more important than it was before. You need a deep understanding not only to guide AI, but to validate what it produces — something you didn't make yourself. The biggest risk across all three phases is cognitive debt: if the team stops owning the domain understanding, they lose the ability to give AI good input, and the whole process degrades.

Domain-driven design remains very valuable — it was always more about helping you think than helping you execute, and that's exactly what's still needed. The thinking, the design of boundaries, the ubiquitous language, the domain model — all of that is still up to us. AI is a good tool, especially given how general-purpose it is. Learn how it works, learn how to prompt it well, and use it in your toolbox. But the design is human.