Separation of Concerns (SoC) is an architectural principle that divides systems into well-defined responsibility areas to improve maintainability and testability. It encourages loose coupling and high cohesion, enabling parallel development and reuse. Applied via modules, layers and explicit interfaces, it also simplifies refactoring.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Executable approach: can be applied and produces an outcome.
What organizes, connects, or makes decisions possible.
Separation of concerns structures a system so that different responsibilities can be handled and changed as independently as possible.
The idea was shaped in software engineering as a response to growing complexity and became known as separation of concerns through Edsger W. Dijkstra. Later architecture and modularization techniques applied it to components, layers, and domain responsibilities.
Look for different reasons to change. Group things that belong together for the same reason, and separate them where independent decisions, tests, or lifecycles emerge.
A concern groups related domain or technical decisions.
Coupling describes how strongly separated parts depend on one another.
High cohesion keeps things with a shared purpose together in a module.
Separation reduces side effects and makes software easier to understand, test, and change. It shapes module boundaries, layers, and team responsibilities.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.