Increased utility of Domain-Driven Development in the context of GenAI Link to heading
These days it sometimes seems like “AI” is the only topic being thrown around in software development circles. Personally I’m mostly ambivalent on the topic but tend to rarely use it: a big - if not the most important - part of software development is asking questions, which is something that LLMs are notoriously bad at. That’s largely because their modus operandi and tuning is aimed to produce good-sounding answers instead of questions. So it tends to funnel output into specific directions - something which can easily be exacerbated through imprudent prompts or subliminal tendencies in their training data.
Secondly, when it comes to actually writing code, I find that their output is generally sub-par and I find myself spending more time refining prompts or cleaning up generated code than if I had just done the implementation myself. Which is an anecdotal datapoint - but is also supported by current research.
But there’s no question that it’s a tool that we need to factor into our work and our development processes. For myself, I have decided that the following two aspects are most important for the work I do:
1. Go Slow Link to heading
While everyone talks about using GenAI to crank out more code more quickly, LLMs are also tools that allow you to make more mistakes faster. By easily following LLM recommendations and generating code all day, one can quickly build up technical debt and evolve code bases that no developer (or automated system) understands anymore.
Thus, we should not let ourselves be hurried into quickly making the wrong decisions but instead keep asking a few more questions and consider potential biases and fallacies. And, as they say in the US Navy Seals, “Slow is smooth, smooth is fast”.
2. Consistently use Domain-Driven-Development Link to heading
LLMs, as the name implies, operate on language. Therefore it is even more important to establish a consistent, ubiquitous domain language in our projects.
As all the methods promoted by DDD are meant to make complex domains more accessible to humans, the same methods are useful for making it more accessible to LLMs, too. So while the original benefit of DDD was to enable better collaboration between software developers and domain experts, we can now throw another partner into the mix: using a distinct terminology throughout the codebase facilitates its comprehension not only for humans, but for software systems, too.
Furthermore, using business process terminology in your API will also clarify intent. In my opinion, the fact that LLMs are nowadays used both for building server and client applications should be good motivation to get rid of CRUD-style HTTP APIs in favour of more domain-oriented ones, too.
Of course, any software architectural pattern should be tied to the degree of complexity and requirements inherent in its domain. And code should be clear about its intent. So when talking about developing non-trivial software, I’m positive that the patterns promoted by DDD will yield even more benefit as the utility of GenAI tools increases.