Domain-Driven Design: A Shift in How I Build

My approach to building software has always been to just start coding and figure it out as I go. I’d dive into an idea, sketch some structures and code from there. But I kept running into this block. A need for perfection that presented in endless refactoring cycles: rename this, move that, try a new pattern. It wasn’t chaos, exactly - more like a constant low-level search for a structure I couldn’t quite see.

I felt this tension building. I was working hard to bring order, but I didn’t know what that order should be based on. I could feel there was some deeper logic to the system I was missing - something beneath the code that I couldn’t quite articulate.

Then I came across Domain-Driven Design by Eric Evans. At first glance, it looked like a deep-dive into software architecture, but as I started reading, it quickly became clear that it was a bit more than that - a way of thinking about software that began not with technology, but with understanding.

Seeing the Domain for the First Time

What really drew me in was Evans’ statement that “the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user.”

I’ve spent much of my career in Financial Services - a space overflowing with complexity that isn’t algorithmic: business rules, regulatory logic, human processes encoded into systems. Yet until I'd grappled with the struggle of building software myself, it hadn't hit home to me how significant this was.

So, I started applying the ideas to the app I was working on at the time. Almost immediately, things started to fall into place. Naming conventions that had always felt arbitrary now made intuitive sense. The relationships between components began to mirror the relationships between concepts in the business domain.

Even practical decisions, like how to structure directories or where certain functions should live, started to become obvious. Logic that belonged to one part of the business naturally grouped together; supporting functions found their rightful homes. The software began to look less like a set of technical files and more like a reflection of the business itself.

Discovering the Invisible Model

As I worked through the refactor, I realised that I hadn’t started from scratch. Long before reading Domain-Driven Design, I’d already built my own domain model. My earlier naming conventions, abstractions, and folder structures weren’t random; they were the physical traces of how I had imagined the system to work.

And that model, created unintentionally, had become a quiet source of constraint, limiting my ability to expand the software to easily accommodate new features. The model wasn’t “wrong”, it was simply a snapshot of my understanding at that point in time, and new features brought new understanding and required the model to develop.

the domain model must be continuously refined as the domain is better understood

Refactoring took on a new meaning. It wasn’t about adding features or improving abstractions anymore - it was about realigning the code with my evolving understanding. Refactoring became a cognitive process as much as a mechanical one.

Building Software Around the Domain

The more I applied Domain-Driven Design, the more I realised that scalable, adaptable software is built around a solid domain model. The model becomes the backbone, the reference point. Once you’ve mapped the domain properly, everything else - from naming conventions to architectural boundaries - can orbit around that understanding. New features stop feeling like intrusions and start feeling like natural extensions.

Without that grounding, every change adds friction. It’s like bolting extra rooms onto a house without a proper floor plan, eventually, you end up with a maze. But when the code is built around a coherent domain model, growth feels organic.

Development as Sense-Making

What surprised me most is how much this changed me. I've stopped seeing myself as someone who writes software about something, and started seeing myself as someone who models that thing. The work became less about features and frameworks, and more about understanding. Conversations with domain experts become design sessions; refactoring became reflection.

There’s a line from cultural theory that says “to name something is to make it thinkable.” That’s what Domain-Driven Design did for my development process. By naming concepts properly - by building shared language between the business and the code - it made the invisible visible. It made complexity tractable.

I now see software design less as problem-solving and more as sense-making. The code is simply the final articulation of that understanding.

Continuous Refinement

The most lasting lesson from Domain-Driven Design is that models, like minds, must evolve. Both the code and the person writing it are continuously refined by experience.

I used to refactor to tidy things up. Now I refactor to think - to clarify what I’ve learned and what the system is really trying to say.

And maybe that’s the quiet philosophy behind Domain-Driven Design: to build better software, you have to keep refining your model - of the domain, the system, and yourself.