Boundaries at the Edge of Control: Where to Draw Abstractions in Frontend Architecture

In almost every team, the same question comes up again and again: where should this code live, should it be extracted into a shared module, is it worth introducing a separate abstraction? It sounds like a routine development discussion, but behind it lies a real engineering decision that can be expensive to undo if you get it wrong.

In this talk, I propose looking at such decisions through a single principle: draw boundaries where your control ends, not where it merely feels convenient or follows convention.

We will start with simple techniques that require no formal methodology: wrapping third-party components and colocating code based on business meaning rather than technical type. Then we will see how the same idea appears in Feature-Sliced Design (FSD) through the api, model, and UI segments, each of which changes for different reasons.

Using real production examples from a Vue-based project, we will explore how isolating backend interactions behind your own contract allows you to fix a single place instead of an entire page, and why abstractions are best introduced when they have earned their existence rather than in anticipation of future needs.

We will also talk honestly about the cost of boundaries: where strict separation is justified, where it turns into overhead, and how to distinguish genuine commonality from accidental similarity. I will share failures as well —cases where I followed architectural best practices to the letter and later had to undo them.

By the end, you will leave not with another list of rules that a search engine can provide, but with a criterion for deciding when to apply those rules and when to ignore them in your own context. The principle is transferable to any technology stack — FSD serves here as an example, not the protagonist.