Interview with Vlad Khononov
Vlad Khononov is a name synonymous with cutting-edge software architecture and Domain-Driven Design (DDD). From his early fascination with computers—sparked by a Soviet ZX Spectrum clone—to becoming a globally recognized author and speaker, Vlad's journey has been shaped by a relentless pursuit of simplicity and clarity in system design.
In this interview, he shares the defining moments that shaped his architectural thinking, including hard-learned lessons from the microservices hype, the influence of Eliyahu Goldratt’s Theory of Constraints, and why modularity remains the key to managing complexity—no matter how fast AI evolves.
Where to find him:
What inspired you to become an architect?
When I was nine, my dad got me a Soviet clone of the ZX Spectrum called “Enter.” I still remember the moment I managed to load my first game—PSSST. It felt unreal. Right then, I knew I wanted to create my own games. After all, what could be more fun than building your own worlds?
Many years later, the games I made are too embarrassing to share, but the joy of being a software engineer never left. For me, becoming an architect wasn’t a goal in itself; it was simply the natural next step to be able to make design decisions at a higher level of abstraction.
Was there a defining moment or project early in your career that shaped your approach?
Yes, when I got my hands on Eric Evans’ Domain-Driven Design (DDD). At the time, I was working at an outsourcing company on a project that was such an insane mess. The codebase was so fragile we were afraid to touch it. I still remember the whole team coming into the office at 2 a.m.—just to deploy a button color change. Seriously.
Reading the DDD book was eye-opening. I realized that things didn’t have to be this way—there are better approaches to software architecture. Eventually, it led me to my next role, where I had the amazing opportunity to apply DDD from day one at a brand-new company. It was a career-defining experience for me.
How would you describe your architectural philosophy in a sentence?
Minimizing the knowledge shared between components and balancing the distance it travels—especially when the source of that knowledge is volatile.
Can you walk us through how you approach a new design project, from concept to completion?
I practice what I preach: design must be driven by the problem it’s meant to solve. So I start by gathering as much information as possible and reducing uncertainty. What’s the business context? What exactly is the problem? Who are the users? Is there competition? I do this both the old-fashioned way—by speaking with stakeholders—and the cool way: EventStorming.
Next, I analyze the implementation context. That means understanding the balance between short- and long-term goals, the organizational structure, how many teams will work in parallel, and other relevant constraints—such as a mandated cloud vendor, team skill sets, or architectural invariants.
For example, in a startup, the priority is short-term: validate the solution, get feedback, and iterate. That context justifies very different design decisions than in an enterprise, as everything—including the problem the system aims to solve—may change as a result.
Then I turn all of that into design decisions. My default is to keep things as simple as possible and only introduce advanced techniques where it’s absolutely justified. This step inevitably leads to more insights, questions, and unexpected uncertainty. That’s where the process becomes iterative.
What’s the biggest challenge you’ve faced in a project, and how did you overcome it?
Jumping on the microservices bandwagon and failing miserably. I was inspired by the field’s thought leaders, followed their guidance, and ended up with a distributed big ball of mud. That failure became a personal vendetta: I needed to understand why it happened and what I did wrong.
This drove me to research coupling in depth, eventually uncovering a rich body of knowledge, some of it dating back to the 1960s, and much of it forgotten today. That experience fundamentally reshaped how I think about modularity, complexity, and system design.
How do you balance creativity with practicality in large-scale projects?
For me, creativity in software architecture means applying an unexpected solution to a problem—using a tool in a way it wasn’t originally intended. For example, using AWS S3 as an operational database.
Of course, these kinds of decisions require rigorous validation to ensure they meet current requirements and can accommodate reasonable future changes. That’s why, in Domain-Driven Design terms, I limit such adventurous choices to supporting subdomains—where both risk and volatility are lower.
What inspires you most in your work as an architect?
Eliyahu M. Goldratt used to say that to think clearly, you must bring reality—no matter how complex it seems—to the point where everyone says, “Well, that’s just common sense.” That’s what he called Inherent Simplicity, and it’s been my guiding principle ever since—whether in Domain-Driven Design, Balanced Coupling, or modeling complex domains in general.
Who or what has had the biggest influence on your thinking and approach to architecture?
Eliyahu M. Goldratt’s Theory of Constraints, Glenford J. Myers’ “Composite/Structured Design,” Geoffrey West’s work on scaling laws, and the whole DDD Community
What trends do you think will define the next decade in architecture?
Honestly, there’s one trend that overshadows everything else: AI. If you’d told me five years ago that AI would pass the Turing test, generate graphics, and write code—I’d have called it wildly optimistic. And yet, here we are.
Given the accelerating pace of innovation, predicting the state of architecture a decade from now feels almost impossible. But if I had to bet, I’d say one thing will still matter no matter what: modular design. Whatever changes, the need to manage complexity won’t go away.
How AI is shaping modern architectural design?
First, in my experience, AI highlights the importance of modular design. Effective module boundaries allow you to fully leverage LLMs. At least now, the smaller and more focused the coding task is, the better the output. Boundaries that minimize shared knowledge across modules make this possible.
Second, AI can be surprisingly useful in exploring business domains. When starting a project in an unfamiliar domain, it can be useful to engage with an LLM acting as a domain expert. While everything still needs to be validated with real stakeholders, it often provides a strong starting point
What advice would you give to young architects just starting their careers?
Learn the principles of modular system design. Understand what complexity is, and how to design solutions that manage it. Once you grasp that, everything else—design patterns, architectural styles, and the new abstraction layers that appear every 5–10 years—will just make sense, as they are concrete implementations of those core principles.
If you could go back and give your younger self one piece of advice, what would it be?
Buy AAPL. On a serious note, read “The Goal” ASAP and meet Eliyahu M. Goldratt while you still can.
What do you think about Dear Architects?
For me, consistency is one of the hardest things to achieve. I truly admire your ability to deliver high-quality content every single week.
Vlad Khononov is a software architect with extensive industry experience, having held roles ranging from webmaster to chief architect. He currently helps organizations make sense of their business domains, untangle monoliths, and address complex architectural challenges. In 2021, Vlad published Learning Domain-Driven Design, followed by his latest book, Balancing Coupling in Software Design, released in 2024. As a keynote speaker, Vlad presents at conferences worldwide on topics such as software architecture, domain-driven design, and the balanced coupling model.