SoC (Separation Of Concerns) Principle

Now we’re handling things simply, ensuring that the required work is revealed in the planned way and in its most minimal form. Amazing. Now we can move beyond the “behavior” context and explore how the principles we’ve acquired can become visible and impactful in the actual product’s operation.

I’d like to discuss the SoC (Separation Of Concerns) principle, which is frequently mentioned by developers. In the “further reading” section, I’ve also included some explanations based on developers’ experiences. You absolutely must take a look.

SoC (Separation Of Concerns)

SoC (Separation Of Concerns) is a design principle that advocates for separating programming code (classes, functions, etc.) based on their functionalities and features. It forms the foundation of many widely adopted software design patterns today. Each element (module) is independent and has its own responsibility (single responsibility) ¹. These scopes are defined by boundaries. The concept of “boundaries” used in the software development process essentially draws a clear line (layer/tier), defining responsibilities and separating them. Within all these concepts, the SoC process guides the division of work into the smallest possible units (functional and responsibility sets) and ensures that the resulting responsibilities remain independent ². This enables development to proceed without disrupting other elements; in the event of a problem, other elements will only be affected within the boundaries defined by the problem. Isn’t this quite similar to the KISS principle?

Of course, the topic should not be considered solely within the context of software development. At its most fundamental level, the separation of CSS files into CSS, JavaScript files into JS, and images into image folders named “img,”, treating HTML, CSS, and JavaScript as separate components, and even protocols such as SMTP can be exemplified by the SoC (Separation of Concerns) approach.

SoC Approach

Two key concepts related to the SoC principle must be mentioned. The coupling (relationship) between software components such as classes or objects, and cohesion (interconnectedness) within the components. Low coupling and high cohesion are preferred in such a structure. This approach leads to a more controlled system design. This mindset plays a key role in enabling software to be flexible and extensible³.

For example, in the MV* pattern, the Model-View-ViewModel (MVVM) pattern frequently discussed in Vue.js articles can be considered. The Model corresponds to the database/data, while the View focuses on the UI/Presentation. The ViewModel acts as a business logic layer and manages the relationship between the View and ViewModel.

Further Reading

1. Applying separation of concerns in the current project
2. Data Vinci 10: Separation of Concerns
3. The Art of Separation of Concerns

Footnotes

1. Separation of concerns, @wikipedia ↩
2. Separation of Concern vs Single Responsibility Principle (SoC vs SRP) ↩
3. What is the separation of concerns in software development? ↩