- by x32x01 ||
“Just a small change.”
Every developer hears this sentence sooner or later. 😅
Sometimes, that small change really is small. Other times, it turns into hours of debugging because one screen is responsible for almost everything:
The trouble starts when you need to change something.
At first, this can feel convenient. You need something, so you add it to the screen.
Then another requirement arrives.
You add another condition.
Then another API response changes.
You update the same file again.
Then a new validation rule is introduced.
Before long, you have conditions inside conditions, functions calling other functions, and logic that depends on several unrelated parts of the screen.
The problem is not necessarily the number of lines.
A 500-line file can be easy to understand if its responsibilities are well organized.
A 150-line file can be difficult to maintain if it mixes several unrelated responsibilities.
That is where Separation of Concerns becomes important.
In simple terms:
Each part of your application should have a clear job.
For example:
The exact architecture depends on the application and framework, but the principle remains the same.
A UI component should not become the place where every type of logic ends up.
The real benefit is that changes become easier to reason about.
Suppose the API response changes.
If API-related code is isolated inside a repository or data layer, you know where to look.
If validation changes, you should not have to search through the entire UI.
If a business rule changes, you should be able to modify that rule without rewriting unrelated presentation code.
This reduces the number of places you need to investigate when something changes.
It also makes the code easier to test.
Instead of testing an entire screen just to verify one business rule, you can test that rule independently.
A poorly organized implementation might handle all of these tasks in one component:
A better structure could separate those responsibilities:
UI: Displays the cart and reacts to user actions.
Repository: Communicates with the payment API.
Business Logic: Calculates discounts and determines whether the order can be processed.
Validator: Checks customer and payment information.
State Management: Tracks loading, success, and error states.
Now, if the discount rules change, you do not need to dig through payment API code or UI rendering logic.
That is the practical value of separation.
Separation of Concerns does not mean creating dozens of folders, interfaces, services, repositories, and classes before writing your first feature.
Over-engineering can create its own problems.
A small application does not necessarily need a complex enterprise architecture.
If a simple function solves a problem clearly, there is no reason to turn it into five classes just because a particular architecture recommends it.
The goal is not:
“Create more files.”
The goal is:
“Give each piece of code a clear responsibility.”
That difference matters.
“Is this really the responsibility of this component?”
If the answer is yes, keep it there.
If the answer is no, consider moving it to a more appropriate part of the application.
For example, if a UI component starts containing database logic, API transformations, and complicated business rules, that is a good moment to reconsider the structure.
You do not need to refactor the entire project immediately.
Start with the responsibility that is causing the most friction.
It is about making change safer.
When responsibilities are clearly separated:
Software will always have complexity.
The goal is to keep that complexity in the right places.
So the next time someone tells you:
“Just a small change…”
You should not have to open one giant file and hope nothing breaks. 😄
A well-structured codebase should make it clear where the change belongs and what parts of the system should remain untouched.
Every developer hears this sentence sooner or later. 😅
Sometimes, that small change really is small. Other times, it turns into hours of debugging because one screen is responsible for almost everything:
- Rendering the UI
- Calling APIs
- Parsing JSON
- Managing state
- Validating user input
- Running business logic
- Handling errors
- Transforming data
- Containing a growing collection of helper functions
The trouble starts when you need to change something.
Why Small Changes Become Difficult
Imagine a screen that handles UI, API requests, validation, state management, and business rules in the same file.At first, this can feel convenient. You need something, so you add it to the screen.
Then another requirement arrives.
You add another condition.
Then another API response changes.
You update the same file again.
Then a new validation rule is introduced.
Before long, you have conditions inside conditions, functions calling other functions, and logic that depends on several unrelated parts of the screen.
The problem is not necessarily the number of lines.
A 500-line file can be easy to understand if its responsibilities are well organized.
A 150-line file can be difficult to maintain if it mixes several unrelated responsibilities.
That is where Separation of Concerns becomes important.
What Is Separation of Concerns?
Separation of Concerns is the practice of organizing software so that different parts of the system are responsible for different concerns.In simple terms:
Each part of your application should have a clear job.
For example:
| Responsibility | Suitable Location |
|---|---|
| Displaying UI | UI / View |
| Reading and sending data | Repository / Data Layer |
| Business rules | Business Logic / Domain Layer |
| Input validation | Validator |
| Application state | State Management Layer |
| Converting API data | Mapper / Model Layer |
A UI component should not become the place where every type of logic ends up.
Why Does Separation of Concerns Matter?
The biggest benefit is not that your project looks cleaner.The real benefit is that changes become easier to reason about.
Suppose the API response changes.
If API-related code is isolated inside a repository or data layer, you know where to look.
If validation changes, you should not have to search through the entire UI.
If a business rule changes, you should be able to modify that rule without rewriting unrelated presentation code.
This reduces the number of places you need to investigate when something changes.
It also makes the code easier to test.
Instead of testing an entire screen just to verify one business rule, you can test that rule independently.
A Simple Example
Consider a checkout screen.A poorly organized implementation might handle all of these tasks in one component:
- Display the cart
- Calculate discounts
- Validate the customer
- Call the payment API
- Format the response
- Update the UI state
- Handle payment errors
A better structure could separate those responsibilities:
UI: Displays the cart and reacts to user actions.
Repository: Communicates with the payment API.
Business Logic: Calculates discounts and determines whether the order can be processed.
Validator: Checks customer and payment information.
State Management: Tracks loading, success, and error states.
Now, if the discount rules change, you do not need to dig through payment API code or UI rendering logic.
That is the practical value of separation.
Separation of Concerns Does Not Mean More Layers Everywhere
There is an important distinction here.Separation of Concerns does not mean creating dozens of folders, interfaces, services, repositories, and classes before writing your first feature.
Over-engineering can create its own problems.
A small application does not necessarily need a complex enterprise architecture.
If a simple function solves a problem clearly, there is no reason to turn it into five classes just because a particular architecture recommends it.
The goal is not:
“Create more files.”
The goal is:
“Give each piece of code a clear responsibility.”
That difference matters.
How to Know When Code Needs Better Separation
There are several warning signs.🚩 One file keeps growing: New features are constantly added to the same component or class.
🚩 Small changes require touching unrelated code: A validation change forces you to modify UI code, API code, and state logic.
🚩 The same logic is duplicated: Multiple screens contain slightly different versions of the same business rule.
🚩 Testing requires the entire application: You cannot test one piece of logic without rendering a screen or making a real API request.
🚩 Developers are afraid to touch the file: If everyone says, “Be careful with that file,” it may be carrying too many responsibilities.
These are not strict rules, but they are useful signals that your code boundaries may need attention.A Practical Rule for Developers
The next time you are about to add code to a large component, stop for a moment and ask:“Is this really the responsibility of this component?”
If the answer is yes, keep it there.
If the answer is no, consider moving it to a more appropriate part of the application.
For example, if a UI component starts containing database logic, API transformations, and complicated business rules, that is a good moment to reconsider the structure.
You do not need to refactor the entire project immediately.
Start with the responsibility that is causing the most friction.
The Real Goal of Separation of Concerns
Good architecture is not about making a project look impressive.It is about making change safer.
When responsibilities are clearly separated:
- Code is easier to understand.
- Individual parts are easier to test.
- Changes are easier to locate.
- Bugs are easier to isolate.
- Different parts of the system can evolve independently.
- Developers spend less time searching through unrelated code.
Software will always have complexity.
The goal is to keep that complexity in the right places.
So the next time someone tells you:
“Just a small change…”
You should not have to open one giant file and hope nothing breaks. 😄
A well-structured codebase should make it clear where the change belongs and what parts of the system should remain untouched.