Interview with Martin Fowler and Eric Evans by Gien Verschatse - DDD Europe 2026

Summary

The interview explores the origins and influence of Domain-Driven Design (DDD), what software teams can learn from earlier technological shifts, and how to work thoughtfully with AI.

DDD’s origins and lasting ideas

• Martin Fowler and Eric Evans first met in the mid-1990s, when Evans invited Fowler to advise on a project after reading Fowler’s work on organizational patterns.
• Their collaboration included an article about a specification template, which later informed material in Evans’s DDD book.
• Fowler highlights bounded contexts as one of Evans’s most important contributions. A concept or piece of information can mean different things in different parts of an organization. Bounded contexts make those distinct models explicit and help teams manage the relationships between them.
• Fowler connects bounded contexts to ubiquitous language: a shared language is central to good object-oriented design, but it is difficult to sustain across a large system without clear boundaries.
• Evans notes that later practices—such as event-oriented approaches, event storming, and domain storytelling—have extended the original idea of collaborating with domain experts in ways he did not prescribe.
• Both speakers feel that DDD and related practices remain less widely used than their value warrants. Fowler also argues that the broader category of analysis patterns deserves more attention.

Lessons from previous technology shifts

• Major technological changes are difficult to predict. The Internet changed software development in ways practitioners anticipated only partly, and its consequences unfolded over time.
• New technology can require a new way of thinking, not merely learning a new framework. The move to Internet applications, for example, made asynchronous behavior much more important and required developers to adapt their mental models.
• Adoption is likely to proceed at human speed, even when the technology itself advances quickly. Organizations need time to understand how new capabilities affect workflows and how to use them effectively.
• The speakers recommend adaptive planning rather than trying to predict a distant future precisely. Make incremental progress, observe what happens, and adjust.

Working with AI and LLMs

• Stay grounded in what current AI tools can actually do. Avoid letting predictions about near-term AGI or other dramatic outcomes distract from practical opportunities and limitations.
• Be skeptical, but also question your own skepticism: track what tools are being used, what they can do, and what experience with real projects reveals.
• Experiment rather than applying AI indiscriminately. Explore alternative architectures and learn enough about how the underlying systems work to build perspective.
• Use scenario planning to consider plausible futures, while remembering that scenarios are possibilities, not predictions. Focus preparation on outcomes where present-day choices could make a difference.
• Expect AI use to require clear language. Fowler suggests that the structures that help humans understand software may also help LLMs work with it. A coherent shared vocabulary can support communication with both domain experts and AI tools.
• Treat LLM output differently from ordinary program output. Because it is not reliably deterministic, generated results need checks before they are trusted or incorporated into a system.

Practical design and engineering practices

• Put safeguards around AI-generated work.
  • Validate the output of each LLM-containing step in a pipeline.
  • Use both “guides” that steer the process and “sensors” that inspect its results.
  • These can be inferential (using another model) or computational (using conventional, deterministic code).
  • Prefer deterministic checks where they can provide reliable, inexpensive verification.
• Keep reviewing and verifying generated code. AI may change how code is produced, but it does not remove the need to read, assess, and revise it.
• Invest in tests and other verification mechanisms. Reliable tests, continuous integration, and related checks help teams judge whether an agent’s changes are safe.
• Preserve human understanding. Writing and coding have traditionally helped developers organize their thinking. If AI takes over more of the production work, teams should consider what practices will replace that learning and design feedback.
• Strengthen professional writing. Clear written explanations can improve communication with agents and colleagues. Fowler cautions that delegating writing wholesale to an LLM may deprive people of the process of organizing ideas and developing understanding.
• Keep domain communication central. Even if AI speeds up code generation, the bottleneck may remain communication between developers and the people who understand the domain. Meet domain experts, learn users’ needs, and improve that collaboration.

Closing recommendations

The speakers’ practical advice is to experiment with AI while staying attentive to its limits, maintain strong review and testing practices, and continue investing in clear communication. Their final emphasis is that understanding the domain and collaborating with its experts remain fundamental to software development.

Speakers and sources mentioned

Speakers

• Gien Verschatse — interviewer
• Martin Fowler
• Eric Evans

People and examples mentioned during the discussion

• Jim Odell — associated with the idea of conceptual modeling
• Laura Tacho — cited in connection with the relationship between agent and developer experience
• Guy Steele — his talk on language development was recommended
• Joshi — referenced in discussion of developing language for communication with LLMs
• Bita Berkeler — credited with an article about harness engineering
• Yann LeCun — the subtitles render his name inconsistently (“Yang Lun” / “Ian Clun”)
• Webvan, Pets.com, and Amazon — cited as examples in a discussion of technology booms and company survival