Skip to main content

Separation of Concerns

Du liest eine Funktion die gleichzeitig Geschäftslogik berechnet, HTML rendert und Daten in die Datenbank schreibt. Jede Änderung ist ein Risiko — weil du nie weißt, was du mitänderst. Das passiert, wenn Verantwortlichkeiten vermischt werden.

Separation of Concerns bedeutet: Jeder Teil deines Systems hat genau eine Verantwortung. Und nur eine.

Denk an ein Restaurant: Der Koch kocht. Der Kellner serviert. Der Kassierer kassiert. Keiner macht den Job des anderen — und genau deshalb funktioniert es.

In Software kennst du das Prinzip aus der Drei-Schichten-Architektur: Präsentation, Geschäftslogik, Datenhaltung. Jede Schicht kümmert sich um ihren Bereich. Aber Separation of Concerns geht tiefer — es gilt für jede Ebene, jede Klasse, jede Funktion.

Der Test ist einfach: Wenn du einen Teil deines Systems ändern musst und dabei einen anderen Teil verstehen musst der nichts damit zu tun hat — dann sind die Concerns nicht getrennt.

Merke: Trennung der Verantwortlichkeiten ist das Fundament jeder guten Architektur.

Trennung der Verantwortlichkeiten ist das Fundament jeder guten Architektur.