Hi everyone!
My name is Dmitrii, and I’ve been working as a frontend developer for the past 11 years. Over my career, I’ve had the chance to build a wide variety of web applications — from small startups to core, high-traffic products for some of the largest tech companies in the country.
This is actually my first article ever and honestly, not the easiest topic to start with. But let’s see how it goes.
I want to start a series of articles on a topic that has been on my mind a lot in recent years — frontend application architecture. Actually, this isn’t just about frontend — many of the ideas apply to software in general, regardless of language or platform. But since my experience is mainly in frontend, that’s the perspective I’ll focus on. Much of this will also apply to backend applications built with Node.js.
Before we begin, if you already have your favorite approach to frontend architecture, that’s great. I’m not claiming to hold the ultimate truth here. What I’ll share is simply a reflection on my personal experience and what I’ve learned over the years — mostly as a full-stack developer (NodeJS + React/Vue) working on projects with constantly changing requirements. You won’t find any revolutionary insights here, just my way of structuring and reasoning about applications. Hopefully, it will give someone food for thought, spark a bit of constructive criticism (which I always welcome), or simply help organize thoughts you might already have.
Motivation
After experimenting with different architectural patterns (Layered Design, Feature-Sliced Design, Atomic Design, Clean Architecture), I realized that none of them fully satisfied me. Each worked well at certain stages of a project’s life cycle — but transitioning from one pattern to another as the system grew was extremely painful, both technically and for the business.
And yet, after a few years, almost every project I worked on naturally evolved into some form of Clean Architecture — or sometimes a mix of Clean Architecture, DDD, and Hexagonal Architecture — often carrying along the technical baggage of the patterns we started with. That’s why I began thinking about how this transition could be made smoother and less painful.
What are Clean Architecture, DDD, and Hexagonal Architecture — and why do we always end up there?
I don’t plan to dive deep into these patterns in this article — many books and articles already do that far better than I could here. But I also can’t continue without providing some context, so I’ll just highlight the essence — the part I believe matters most right now.
Clean Architecture, DDD, and Hexagonal Architecture are slightly different approaches to implementing one simple idea: separating business logic from everything else. The goal is to make the system easier to maintain and evolve.
This idea might sound simple — but in practice, it’s the very thing that determines whether a project will continue growing for years or eventually turn into a hard-to-evolve system, where each new feature takes longer to implement and confidence in its stability keeps shrinking.
What’s next
In the next article, I’ll go deeper into this and show how I prefer to structure applications at the highest level of abstraction — starting with how I separate them into modules and layers.
Top comments (0)