AI Makes Implementation Cheaper. That Makes Domain Definition More Important

A lot of the current AI discussion in software engineering focuses on implementation getting faster. That matters, but it also moves the risk somewhere else: before implementation starts, when the team is still deciding what the system should become.

Domain-driven design is something that lends itself well to the kinds of larger projects I often see in an agency environment: booking engines, appointment systems, property platforms, and other applications where the complexity is not just technical.

The common thread is that these systems have a real domain behind them. There is a language, a set of rules, and a model of the business that needs to make sense both in code and in conversation.

But despite being interested in DDD for a long time, I have rarely seen it chosen explicitly for agency projects. Not because the idea is wrong. Usually the opposite - the projects that could benefit from DDD most are often the ones under the most pressure.

The definition work takes time. The modelling takes time. Getting the right people into the room takes time. When a project is shaped by fixed budgets, compressed timelines, and limited stakeholder availability, DDD can be easy to agree with in principle and difficult to fund in practice.

That is where AI starts to change the calculation slightly.

Not because it removes the need for domain thinking, but because it can reduce some of the cost around the work. It can help inspect existing systems, summarise behaviours, compare terminology, surface repeated concepts, draft candidate models, and turn messy legacy knowledge into something the team can discuss.

That is especially true on legacy rebuilds.

The old system already exists. It has screens, workflows, database tables, services, reports, integrations, and years of accumulated behaviour. A lot of the domain information is already baked into the system. The problem is that it is not usually expressed cleanly.

Some of it is useful business knowledge. Some of it is accidental complexity. Most of the difficulty is working out which is which.

Older systems tend to show the same patterns. Useful business knowledge is bundled together with technical compromises. Language has drifted over time. One concept appears in several places but means slightly different things depending on the workflow.

That last one is especially common. A word might mean a public-facing item in one part of the system, a managed internal record in another, a commercial object somewhere else, and a content item in another context entirely. The word is the same, but the concern is different.

The temptation with a legacy rebuild is to jump straight into implementation. You have the code. You can see what the system does. There are screens to copy, workflows to reproduce, and database tables to inspect. It can feel like the quickest route is to rebuild what is already there, just with newer technology. But there is good reason to wait.

A legacy system is rarely one clean layer of intent. It can be fifteen years of requirements, fixes, workarounds, client requests, changing business rules, and technical compromises layered on top of each other. Some of that needs to be carried forward. Some of it needs to be challenged. Some of it only exists because nobody had the time or context to model it differently at the time.

That is why the definition work in a legacy rebuild is so valuable. It is also why it has historically been expensive.

The old system is evidence, not truth

One of the most useful ways to think about a legacy system is that the old system is evidence, not truth.

It tells you what the business needed at different points in time. It shows where rules were enforced, where exceptions were added, where terminology drifted, and where the system had to bend around real-world constraints. But it does not tell you which of those things still matter.

That distinction changes how you approach the rebuild. If you treat the old system as the specification, the work becomes mostly an exercise in translation. Old screen to new screen. Old table to new table. Old behaviour to new behaviour.

Sometimes that is necessary. A rebuild does need to preserve important business behaviour, and users will still expect the new system to support the work they already do.

But if that is all you do, you miss the chance to understand the domain properly before rebuilding it. You also risk preserving complexity that only existed because of the old system itself.

This is where DDD becomes useful. Not as a heavy theoretical exercise, but as a way to ask better questions about the system being rebuilt.

Where are the real boundaries? Where has one concept been overloaded? Which terms need clearer meaning? Which behaviours represent actual business rules, and which are just leftovers from old implementation choices?

Concepts like bounded contexts and ubiquitous language are useful here because they force the team to be more explicit about meaning. That matters on a rebuild, because the old system can make things look more settled than they really are.

The issue is not whether that kind of modelling has value. Most engineers can see the appeal once they have worked on a complex enough system. The harder question is whether the team can create the space to do it properly, especially when the project still needs estimates, timelines, scope decisions, and visible progress.

That is the practical barrier.

DDD is attractive because it promises clearer boundaries, better language, and a model that is easier to reason about over time. But in practice, the cost is not only the modelling. It is the work around the modelling: workshops, diagrams, notes, model revisions, stakeholder conversations, and repeated attempts to get the language right.

That work is easy to squeeze when delivery pressure rises.

Using AI to get to a better first pass

On a recent project, we were looking at a long-serving legacy application that modelled a real business domain. It had more than fifteen years of behaviour, terminology, rules, workflows, and edge cases embedded inside it.

That made it a good candidate for DDD, not because the existing system already had clean domain models, but because it contained a lot of domain evidence. There was useful knowledge in the codebase, and there was also useful context from people who had maintained the system, worked with the client, and understood how the business had changed over time.

The challenge was turning that into something we could reason about. This is where AI helped.

I could ask an AI agent to scan the existing solution and look for patterns that might indicate candidate domain concepts. It could identify repeated terms, possible aggregates, lifecycle transitions, candidate bounded contexts, and places where the same concept appeared to be used in different ways.

It was also useful for spotting seams. If the same word meant one thing in one workflow and something subtly different somewhere else, that was a signal worth investigating. Not proof of a boundary, but a clue that the system might be carrying more than one model under the same name.

It could also produce a first pass at a ubiquitous language glossary, including ambiguous terms that seemed to have different meanings in different parts of the system.

The value was not that AI discovered the domain for us. It did not - that still needs human judgement, business context, and the right conversations with the right people.

The value was that AI helped turn a messy legacy system into a better starting point for modelling conversations.

Instead of starting from a blank page, we could start with candidate concepts, suspected boundaries, ambiguous terms, and specific questions for the people who understood the business. That is a much better use of stakeholder time than asking everyone to reconstruct the domain from memory, or expecting engineers to manually reverse-engineer every important concept from the codebase before the modelling conversation can even begin.

The process became a series of modelling passes over the existing system.

The first pass was about language. What terms appeared repeatedly? Which names seemed important? Which concepts showed up across multiple areas of the codebase?

The next pass looked at behaviour and lifecycle. Where did important state changes happen? What actions caused those changes? Which parts of the system looked like they were protecting business rules rather than just moving data around?

From there, we could start looking for candidate boundaries. Not final bounded contexts, but areas of the system that seemed to have their own language, rules, and workflows.

The outputs were deliberately treated as draft material. They included a candidate glossary, ambiguous terms, possible bounded contexts, candidate aggregates, lifecycle states, domain events, stakeholder questions, and areas where the legacy system looked accidental rather than intentional.

The output was not there to replace the modelling conversations. It was there to improve them.

It gave the team something concrete to react to. It helped surface assumptions earlier. It made ambiguities visible. It also made it easier to separate the parts of the old system that represented real domain knowledge from the parts that looked more like historical compromise.

That is where I think AI starts to make DDD more achievable in practice. Not by doing the modelling for us, but by reducing the cost of getting to a useful first conversation.

The first pass was not enough on its own. With the draft material in place, the next step was to test it against a small proof-of-concept vertical slice.

That mattered because a model can look reasonable in a diagram and still fall apart once it has to support real behaviour. The slice forced the candidate concepts to do some work. Could the aggregate protect the right rules? Did the lifecycle make sense? Were the proposed events useful, or just noise? Did the boundary still feel natural once code started to form around it?

In that sense, the PoC acted as a governor on the AI-assisted discovery work. If a suggested boundary led to awkward coupling, unclear responsibilities, or a model that was difficult to implement cleanly, that was evidence against the model, not a reason to force the code to fit it.

It did not prove the whole system design was right. But it gave the team something concrete to inspect, challenge, and improve.

AI helped reduce the cost of getting to a candidate model. The vertical slice tested whether that model was worth taking seriously.

What AI does not solve

It is worth being clear about what AI does not solve here.

It can infer patterns from the system, but it cannot decide what the future system should become. It does not know which business rules still matter, which behaviours exist because the business genuinely needs them, or which ones are only there because the old system made better options difficult. It also does not know which terms are politically sensitive, which workflows are painful for users, or which parts of the process have already changed in practice but not in code.

That still needs people.

It needs engineers who can recognise accidental complexity, stakeholders who understand the business, and product and delivery people who can help separate what must be preserved from what should be improved. AI can make those conversations better prepared, but it cannot replace them.

There is also a risk of false confidence. A model generated from a legacy system can look convincing because it is structured, named, and presented neatly. That does not make it right.

It may simply be a clean summary of old confusion.

That is why the outputs need to be treated as drafts. Useful drafts, but drafts.

The job of the team is still to interrogate them. Does this boundary make sense? Does this event represent a real business moment? Is this aggregate protecting behaviour, or just grouping data together because the old database did? Are we modelling the domain as it should be, or just recreating the old system with better naming?

Those questions still matter. In some ways, they matter more now, because AI can make weak ideas look more complete than they really are.

Why this changes the economics

The reason this matters is not because AI suddenly makes DDD easy.

It does not.

The reason it matters is that it changes the cost and risk of getting to the first useful version of the work.

Historically, a lot of the early effort in a legacy rebuild sits in understanding the existing system. You need to find the important concepts, trace behaviours, identify rules, work out where the language has drifted, and turn all of that into something the team can reason about.

That is slow work.

It is also exactly the kind of work that can be hard to justify at the start of a pressured project. Everyone agrees it is valuable, but the project still needs estimates, timelines, scope decisions, and visible progress.

AI helps because it can reduce some of that early manual effort. But the more important benefit is risk reduction. The win is not just starting the modelling work more cheaply. It is reducing the chance that the team spends months rebuilding a cleaner, faster version of a process it should have challenged.

It can get the team from legacy code to candidate concepts more quickly. It can generate first-pass documentation. It can surface repeated language and suspicious ambiguity. It can help prepare workshop material. It can produce enough structure that the expensive human time is spent on judgement rather than extraction.

The domain experts still need to be involved. The engineers still need to make design decisions. The model still needs to be tested, revised, and kept alive as the system changes.

But the starting point is better, and the cost of getting there is lower.

For agency projects, that matters. A small reduction in discovery overhead can be the difference between domain modelling being seen as an expensive ideal and being seen as a practical part of the rebuild.

That does not mean every project needs full DDD. It does not mean every legacy system deserves the same level of modelling. But it does mean the option becomes more realistic in places where it previously might have been ruled out too quickly.

Implementation is getting cheaper. I have written about that from the maintenance side: getting to a first version is no longer the hard part in the same way, but keeping the system coherent as it grows still is.

That is useful, but it also changes where the risk moves.

If implementation is faster, then rebuilding the wrong thing is faster too.

You can reproduce old workflows more quickly. You can migrate bad assumptions more efficiently. You can copy accidental complexity into a new architecture with more confidence than it deserves.

That is why definition work becomes more important, not less.

In a legacy rebuild, the question is not just “can we rebuild this system?” It is “what should this system become?”

That question cannot be answered by code alone.

It needs domain understanding. It needs language. It needs boundaries. It needs a way of deciding which parts of the old system represent the real business and which parts represent history, compromise, or drift.

AI can help with that work, but only if it is used in the right place.

Not as the domain expert.

As a way of making the existing system easier to inspect, the candidate model easier to discuss, and the definition work easier to justify.

Where this leaves us

The old system is not the specification. It is evidence.

It shows what happened, what changed, what was compromised, and what accumulated over time. The job of a rebuild is not to copy that evidence into a newer stack. It is to understand it well enough to decide what should come next.

That is why definition work matters more as implementation gets cheaper.

If implementation keeps getting cheaper, the advantage will not come from building faster by default. It will come from being clearer about what is worth building in the first place.