Building software that works, continues to work, and can be easily adjusted is the ultimate goal of any project. To get there, I need a rock-solid foundation—a clear conceptual map in my head of how the entire system operates. I don’t understand how people can do it any other way!
I use AI coding agents. And I’ve seen what happens when backend architecture is treated as an afterthought and left entirely to the AI because we mistakenly believe that knowing that stuff doesn’t matter anymore. We just let the AI do it. It works for getting a prototype off the ground quickly, but it can rapidly turn into a nightmare. Jumping into projects quickly that we wouldn’t have tried to build before is fun and exciting but once the high wears off the reality is bleaker. In the era of “vibe coding,” strict architecture is more important, not less. If the programmer doesn’t understand the big picture, and if the code doesn’t accurately model the real-world use case, we lose the ability to build on it. When an AI agent lacks clear boundaries, it tends to hallucinate connections that shouldn’t exist, creating a mess that no one understands. Domain-Driven Design (DDD) and Ash solve this for me. In DDD we craft code that mirrors the real-world expertise of domain experts, we build software where every action and function uses the actual vocabulary of the business. The actions in our code map directly to the actions already being carried out by the workers. A domain expert could look at the code and have an idea of what it does with little explanation. In DDD we use a “bounded context” (called a domain in Ash) that models the business. For instance, if we are building software for a shipping company, a bounded context might be Shipping.Sales or Shipping.Receiving. Our code will then use the processes and language specific to those domains. Domain Driven Design gives us a blue print of the domain and then the actions needed to build it. Instead of crafting rules; do this then do that.
In DDD we do it differently. For example let’s say our sales department needs to create quotes. So we would build a quote resource in the Shipping.Sales domain. We would then define the actions that we can run on that resource. So to create the quote we would run the create action on the quote resource in the sales domain.
Say we were building a house like we build software systems. Most people would use a set of rules for how to build the house but domain driven design is different. In DDD we would build the blue print first (the domain) then pick out the material for the house (the resources) and then describe what actions need to be performed on the resources.
A person building a house for years just for his family could use all sorts of crazy building methods and they may work. There are a lot of crazy houses out there. Just look at this guy living on an island off British Columbia.
That house is cool but it would be hard for anyone other than the man who built it to grasp what is happening, how to maintain it, and how to add on to it. He couldn’t simply call up a local contractor and have him make an addition or change the layout of the kitchen.
And we don’t want software like that, especially for business or for consumer web apps. We need to use a standard, modular building system, like DDD and Ash so that we can be the architect that understands the whole building and builds it in such a way that the robots can make the additions without making a mess of things.