Interview with Andrew Harmel Law
In this interview, Andrew shares a refreshingly practical and deeply human perspective on software architecture, grounded in his passion for domain-driven design (DDD).
His philosophy centers on the idea that great architecture is about making sense of complex domains. Always prioritizing real user needs, clear communication, and sustainable evolution.
Andrew’s insights reveal how DDD isn’t just a set of tools, but a mindset that empowers teams to build systems with true conceptual integrity. If you believe architecture should make life better for real people, Andrew’s reflections offer the kind of hard-won wisdom and honest insight that can truly change how you see your work
Where to find Andrew:
What inspired you to become an architect?
I wanted to work in software since writing a C-based neural network at university in my Psych degree. Once I started work at Sun Microsystems I realised distributed computing was a thing, and I took a J2EE architect certification. For that a colleague introduced me to Craig Larman’s Applying UML and patterns. I am a visual thinker, and to be able to think about software with diagrams was mind opening.
Later in life I was a software consultant at Capgemini. I was trying to model the domain for my client - the Scottish legal system, and I couldn’t make it all fit at all. Then I took Eric Evans’ Domain-Driven Design immersion course and learned about bounded contexts and ubiquitous language.
Later on, when I was working for Thoughtworks I made time to go back and read Christopher Alexander’s The Timeless Way of Building and A Pattern Language. I saw how important the language aspect of patterns was. Their interconnectedness, and even more importantly, how it is important that everyone can communicate in it.
Was there a defining moment or project early in your career that shaped your approach?
As I mentioned above, the defining moment was when I was trying to make a single domain model of the whole Scottish Justice system. When I saw that the mental models of the domain experts, and the words they used to describe them in different contexts, was the key to solving my architectural complexity challenges my mind was opened. It shapes my every act as a software architect to this day. It amazes me how powerful Eric’s blue book is to this very day.
How would you describe your architectural philosophy in a sentence?
The architecture that is running is the only one that matters, and the primary goal of that architecture is to tackle the complexity inherent in the domain. Every other concern is secondary.
Can you walk us through how you approach a new design project, from concept to completion?
My philosophy that I just articulated is very domain-driven. Understanding domains at the earliest opportunity helps me focus, prioritise, and design systems that have conceptual integrity. I do this by collaborating with domain experts as closely and as much as possible to understand their mental models. As I do I co-design with them, listening to their language and co-creating a design that works for the task(s) in hand.
But it’s not one and done. I iterate. Iterate iterate iterate. Being domain focused allows me to move on this fast, and prioritise iterative changes that enhance the resulting designs. I’ve learned that as teams grow, domain-alignment allows me to collaborate in helping them be stream aligned, and manage their bounded contexts, and consequently their cognitive load.
That’s because being domain-driven helps me focus on the gaps and relationships while teams focus in their specific areas. Not everyone needs to know everything about everything, including me. DDD gives me tools like context maps, domain vision statements, and the many other strategic design patterns to make this all work. That then makes the space for experts in other areas to bring their expertise to bear too.
What’s the biggest challenge you’ve faced in a project, and how did you overcome it?
Trying to make a single domain model fit a complex domain. Then I realised different models are required for different tasks.
How do you balance creativity with practicality in large-scale projects?
Keeping top of mind the job(s) to be done by the software, as well as the fact that software is only a tool, not the answer to everything, always keeps me on track.
What inspires you most in your work as an architect?
The domain, and the importance of a shared, co-created understanding
Who or what has had the biggest influence on your thinking and approach to architecture?
DDD (Blue Book), Applying UML and Patterns, Enterprise Integration Patterns, Object Oriented Development at work, socio-technical architecture.
What trends do you think will define the next decade in architecture?
The reasoning about architecture needs to not be handed off to others.
How AI is shaping modern architectural design?
It is in danger of stopping us doing the knowledge
What advice would you give to young architects just starting their careers?
Listen to the domain. Listen to your users. Realise that an architecture has to be developable, testable, and evolvable
If you could go back and give your younger self one piece of advice, what would it be?
Listen to the domain. Focus on what an architecture does. You don’t need to make the decisions, but you do need to make sure that they are happening, and that everyone involved in delivery understands that.
What do you think about Dear Architects?
I love how it brings together the latest thinking and conversations from a wide variety of sources and voices.
A Tech Principal at Thoughtworks, Andrew specializes in domain-driven design, org design, software and systems architecture, agile delivery, build tools and automation.
Andrew is also an author and trainer for O’Reilly. They’ve written one book about facilitating software architecture and one chapter about implementing the Accelerate/DORA four key metrics. They also run regular online training sessions in Domain-Driven Design (First Steps) and Architecture Decision Making by Example.
Experienced across the software development lifecycle and in many sectors, what motivates them is the humane delivery and sustainable evolution of large-scale software solutions that fulfill complex user needs. They understand that people, architecture, process and tooling all have key roles to play in achieving this.
Andrew has been involved with OSS to a greater or lesser extent since their career began; as a user, contributor, expert group member, or paid advocate—most notably as one of the Jenkins JobDSL originators.
Andrew enjoys sharing their experience as much as possible. This sharing is not only seen in their formal consulting engagements and writing, but also informally through mentoring, blog posts, conferences (keynoting, speaking and organising), and open-sourcing their code.