https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

In computer science, separation of concerns (SoC) is a software engineering principle that allows software engineers to deal with one aspect of a problem so that they can concentrate on each individually. Concerns can be separated in various ways. Separation of concerns in terms of time is the underlying motivation of software development lifecycle methods.

Edsger W. Dijkstra in his 1974 paper "On the Role of Scientific Thought", coined the term separation of concerns in relation to software qualities such as correctness and efficiency.

Carlo Ghezzi in his book "Fundamentals of software engineering" promotes Separation Of Concerns as the primary way to tackle the inherited complexity in software production.

Philippe Kruchten in his article "Architectural Blueprints—The “4+1” View Model of Software Architecture" used a model composed of five main views to address large architectures, essentially this is a view-based separation of concerns, where each view focus on a different aspect of the architecture.

According to Carlo Ghezzi, the main benefit of software modularity is that it allows the application of the separation of concerns principle to system components, or "modules." Module details can be addressed in isolation; furthermore, module integration is treated as a separate concern that deals with the overall characteristics of software modules and their relationships.

Laplante, Phillip also mentioned that separation of concerns can be applied in software design, coding, time, and software qualities.

The Independent Variation Principle (IVP), an actionable 2025 formalization of separation of concerns for software design, expresses this as: "separate elements that vary independently; unify elements that vary dependently." When applying the IVP to a system, Edsger W. Dijkstra's aspect, or concern, which should be studied in isolation, is all the knowledge which is subject to a single change driver (equivalent to Robert Cecil Martin's "reason to change" in the Single responsibility principle and Common Closure Principle) and which is relevant to implement the system's functionality and qualities (non-functional requirements). The IVP operationalizes Carlo Ghezzi's conclusion on modules by providing clear guidance to define causal module boundaries aligned with the organisation's decisional structure.