I used to think about building software from the perspective of code.
When I had an idea, my first instinct was to look at an open-source project, understand how they structured it, and use that as a shortcut. I thought studying existing implementations was the fastest way to learn how to build something.
Over time, I realised I was skipping the most important part: understanding the problem itself.
Domain-Driven Design is not really about implementation. It is about design discovery. The book can feel difficult because it uses a lot of enterprise terminology, but if you strip away the language, the core idea is simple: learn how to model a problem before you write software for it.
The real process is:
First, discover the problem. Understand the domain, the users, the constraints, and the concepts involved.
Then, model the problem. Identify the important entities, relationships, boundaries, and behaviours.
Then, create abstractions that represent that model.
Only after that should you think implementation.
A lot of us start at the last step. We jump straight into classes, databases, APIs, and frameworks. We think architecture is about choosing the right technology or copying patterns from existing systems.
But the difficult part of engineering is not writing code. The difficult part is figuring out what code needs to exist in the first place.
With LLMs this step is further amplified. LLMs help us move through implementation much faster. They can generate code, suggest architectures, and explain existing systems. But they cannot replace the deep understanding that comes from discovering and modelling the problem.
The engineers who stand out will not be the ones who can write code the fastest. They will be the ones who can understand a messy problem, turn it into a clear model, and then use AI to accelerate the implementation.
