Loading content
Separation of Concerns (SoC) ist ein Architekturprinzip, das Systeme in klar abgegrenzte Verantwortungsbereiche trennt, um Wartbarkeit und Testbarkeit zu verbessern. Es fördert lose Kopplung und hohe Kohäsion, erleichtert parallele Entwicklung sowie Wiederverwendung und reduziert Komplexität und erleichtert Refactoring.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Ausführbares Vorgehen: kann angewendet werden und erzeugt ein Ergebnis.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Trennung von Verantwortlichkeiten ordnet ein System so, dass unterschiedliche Aufgaben möglichst unabhängig voneinander bearbeitet und verändert werden können.
Die Idee wurde in der Softwaretechnik als Antwort auf wachsende Komplexität geprägt und durch Edsger W. Dijkstra als Separation of Concerns bekannt gemacht. Spätere Architektur- und Modularisierungstechniken übertrugen sie auf Komponenten, Schichten und fachliche Zuständigkeiten.
Suche nach unterschiedlichen Gründen für Änderungen. Bündele Dinge, die aus demselben Grund zusammengehören, und trenne sie dort, wo unabhängige Entscheidungen, Tests oder Lebenszyklen entstehen.
Ein Concern bündelt zusammengehörige fachliche oder technische Entscheidungen.
Kopplung beschreibt, wie stark getrennte Teile voneinander abhängen.
Hoher Zusammenhalt hält in einem Modul Dinge mit gemeinsamer Aufgabe zusammen.
Die Trennung reduziert Seiteneffekte und macht Software verständlicher, testbarer und veränderbarer. Sie prägt Modulgrenzen, Schichten und Teamverantwortung.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.