Domain-Driven Architecture in the Frontend, Part 1

What is Domain Driven Architecture and how it can help you manage complexity in your frontend codebase?

Photo by Kimon Maritz on Unsplash

This article is about what domain-driven architecture is, why it could help you, and how I’ve learned to implement it in the front.


This one goes out to any frontend developer that has ever found themself dreading the thought of working on a codebase because it’s just too hard to follow what anything is doing anymore.

I’m writing this because I’ve been there myself: you start working on a project and in the beginning, everything is a breeze. But as it grows it becomes harder and harder to get anything done on it. Over time, something that was exciting becomes a hassle, and the motivation to work suffers because of it. This can happen even if you follow best practices and the recommended style guide to the letter. If you can relate, then domain-driven architecture can help you.

The domain-driven architecture I propose here is one implementation of some of the principles of domain-driven design (DDD), the development philosophy defined by Eric Evans in “Domain-Driven Design: Tackling Complexity in the Heart of Software” (2003).


One of the main reasons this architecture is put in place is to help developers manage the complexity which increases over time in the codebase.

Another reason is to enable developers to focus most of their attention and intelligence on thinking about the problem the business is solving (its domain).

In other words, we tell devs:

“Focus on figuring out the best solution possible. When you need to implement it just follow the architecture”.

Architecture decisions are usually limits we impose on our liberty as devs, but which in return increase the organization, predictability, readability, and testability of the project. Domain-driven architecture increases the initial cost of building a project, but greatly reduces the cost of maintaining it. Domain-driven architecture is thus justified for any solution projected to exist (and evolve) in the long term.

One of the main reasons software becomes complex and difficult to manage is due to the mixing of domain complexities with technical complexities. Evans describes this problem as “code that does something useful, but without explaining how”.
(Patterns, Principles, and Practices of Domain-Driven Design. Scott Millett, Nick Tune, 2015)


Before going over the particular architecture decisions I have learned to follow and how they’ve helped me and my team, let’s go over what a typical frontend application looks like.

The “problem”

Check this representation of a typical frontend architecture design taken straight from Huy Ta Quoc (link to the resource below). Does it look familiar?

Domain-Driven Architecture in the Frontend, Part 1 was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

(Visited 1 times, 1 visits today)