50 Jahre Kohäsion - und immer noch unklar?

This blog post is also available in English

TL;DR

• Kohäsion ist uneindeutig, weil „Zusammenhang" je nach Architekturziel unterschiedlich verstanden werden kann.
• Funktionale Kohäsion misst, ob Elemente demselben Zweck im Systemkontext dienen.
• Kohäsion betrifft eine Komponente; falsch platzierte Logik erhöht Kopplung, nicht Kohäsion.
• Ein Hinweis auf schlechte Modularisierung sind Komponentenbeschreibungen mit „und", Zeitbezug oder unspezifischem Objekt.

Für einen Kundenworkshop wollte ich die Taktiken „Kopplung verringern" und „Kohäsion erhöhen" neben anderen Architekturtaktiken diskutieren. Dafür brauchte ich eine möglichst einfache und präzise Definition dieser Begriffe (kurz genug, dass sie auf eine Karteikarte passte).

Im Fall von Kopplung war das relativ schnell erledigt: Hier gibt es einige Definitionen, die letztlich alle auf das Maß hinauslaufen, in dem Änderungen an einer Systemkomponente auch Änderungen an anderen Komponenten nach sich ziehen [1].

Im Fall von Kohäsion war es deutlich schwieriger. In meiner Vorstellung beschrieb Kohäsion irgendwie, wie viel die Dinge in einer Komponente miteinander zu tun haben. Auch in der Literatur sind die Beschreibungen oft nicht deutlich präziser:

Beispielsweise beschreiben Constantine und Yourdon [1] Kohäsion als „intramodular functional relatedness". Bass, Clements und Kazman [2] beschreiben Kohäsion als die Wahrscheinlichkeit, dass ein Änderungsszenario, das eine Verantwortlichkeit einer Komponente betrifft, auch andere Verantwortlichkeiten derselben Komponente betrifft. Das ist schon etwas konkreter, aber etwas umständlich und lässt die Frage offen, was genau unter Verantwortlichkeiten zu verstehen ist. Für meine Karteikarte habe ich diese Definition trotzdem übernommen und dann beim Workshop in viele fragende Gesichter geschaut. Auch bei Diskussionen mit Kolleg:innen hat sich herausgestellt, dass die Meinungen, worum es sich bei Kohäsion handelt, weit auseinandergehen. Ich will daher versuchen, in diesem Artikel genauer zu verstehen, worum es sich bei Kohäsion handelt. Dabei wird sich zeigen, dass Kohäsion kein absolutes Maß ist, sondern stark vom Kontext und den Qualitätszielen abhängt, die man mit der Modularisierung des Systems verfolgt.

Warum teilen wir Software in Komponenten auf?

Kohäsion ist eine Eigenschaft einer Komponente in einem größeren System. Das Konzept soll dabei helfen, eine (für den konkreten Anwendungsfall) nützliche Aufteilung eines Systems in Komponenten zu finden.

Die Idee, Software in Komponenten aufzuteilen, wurde bereits in Dijkstras T.H.E.-System [3] genutzt, um die Komplexität des Gesamtsystems zu reduzieren. Auch David Parnas [4] sah Modularisierung als einen Weg, die Änderbarkeit und Verständlichkeit eines Systems zu verbessern.

Im Kern ist die Motivation für Modularisierung, dass das Gesamtsystem zu groß ist, um als Ganzes fassbar zu sein, sodass es sich lohnt, jeweils nur kleinere Teile des Systems betrachten zu müssen.

Was ist Kohäsion?

Der Begriff „Kohäsion" wurde (gemeinsam mit Kopplung) von Stevens, Myers und Constantine [5] eingeführt. Die primäre Motivation war es, Modularisierungen eines Systems zu finden, die es leicht machten, Änderungen lokal ohne Auswirkung auf andere Teile des Systems durchführen zu können. Eine zweite Motivation war auch hier, die Verständlichkeit und Nachvollziehbarkeit des Systems zu erhöhen. Änderungen möglichst lokal durchführen zu können, ist letztlich die Definition des Begriffs „Kopplung".

Kohäsion (von lateinisch cohaerere, zusammenhängen) wurde von Stevens, Myers und Constantine aufgrund einer einfachen Heuristik eingeführt: Wenn man Elemente eines Systems, die stark miteinander zusammenhängen, in derselben Komponente zusammenfasst, dann reduziert man die Abhängigkeiten zwischen verschiedenen Komponenten, denn die hohen Abhängigkeiten wurden ja in die Komponenten verschoben.

Analog zu anderen Disziplinen wie der Soziologie wählten Stevens, Myers und Constantine den Begriff „Kohäsion", um dieses hohe Maß an Zusammenhang innerhalb einer Komponente zu beschreiben.

Was bedeutet „zusammenhängen"?

Es gab vor einer Weile eine Diskussion bei INNOQ, ob denn java.lang.Math (die Java-Standardbibliothek-Implementierungen wichtiger mathematischer Funktionen) eine hohe oder niedrige Kohäsion habe.

Die Argumente für beide Seiten waren im Wesentlichen:

• java.lang.Math hat hohe Kohäsion, denn alle Elemente sind grundlegende mathematische Funktionen.
• java.lang.Math hat niedrige Kohäsion, denn die Elemente sind voneinander unabhängig implementiert (das ist nicht ganz wahr, aber für die Diskussion hier können wir mal annehmen, es wäre so).

Was bedeutet also „Zusammenhang"? Dass Dinge voneinander abhängen (also eine Art „interne Kopplung") oder dass sie fachlich viel miteinander zu tun haben?

Stevens, Myers und Constantine liefern selbst schon eine Antwort auf diese Frage, indem sie verschiedene Stufen von Kohäsion beschreiben, darunter die höchsten Stufen der sequentiellen (darunter würde fallen, dass Ausgaben eines Elements als Eingaben für das nächste dienen) und funktionalen Kohäsion (die Elemente dienen einem fachlichen Zweck). Die Frage, ob java.lang.Math hohe Kohäsion hat, hängt also in diesem Sinne wesentlich davon ab, ob man „mathematische Funktionen bereitstellen" als fachlichen Zweck sieht oder nicht.

Das zeigt, dass der Begriff des Zusammenhangs stark davon abhängen kann, in welchem Kontext und mit welchem Ziel die Modularisierung des Systems betrachtet wird. Das erklärt auch, warum es so viel Uneinigkeit gibt, wenn man die Frage stellt, was Kohäsion eigentlich bedeutet, und warum Definitionen von Kohäsion oft etwas schwammig bleiben.

Wozu brauchen wir Kohäsion?

Wir gehen einen Schritt zurück und schauen noch einmal auf die Motivation hinter dem Begriff „Kohäsion". Hohe Kohäsion ist kein Selbstzweck. Sie ist ein Mittel (eine Qualitätstaktik) zur Erreichung übergeordneter Qualitätsziele. Je nachdem, welche Ziele das sind, kann ein unterschiedlicher Begriff von „Zusammenhang" nützlich sein.

Für java.lang.Math gibt es zwei Ziele, die relevant sein könnten:

• Java-Entwickler:innen sollen die Standardbibliothek gut benutzen können. Dafür ist es wichtig, dass Funktionalität leicht gefunden werden kann. Für mich als Java-Entwickler ist es klar, dass ich in java.lang.Math suche, wenn ich eine mathematische Funktion brauche. (Dieses Ziel ist durch IDE-Unterstützung inzwischen weniger relevant, als es vermutlich zu Beginn der Entwicklung der Java-Standardbibliothek war.)
• Neue mathematische Funktionen und Performance-Optimierungen der bestehenden mathematischen Funktionen sollten durch die Komponentenstruktur unterstützt werden.

Beide Ziele legen nahe, dass es eine gute Idee ist, alle Elemente in eine Komponente zu gruppieren, die den Zweck „mathematische Funktionen bereitstellen" erfüllen.

Auf der anderen Seite ist die Frage, ob sich Elemente einer Komponente gegenseitig aufrufen, sehr relevant, wenn das Ziel etwa bessere Verständlichkeit oder Änderbarkeit des Systems ist. Auch hier wird wieder klar, dass die konkreten Ziele einen großen Einfluss auf die Bewertung der Kohäsion haben.

Zweck und Beschreibungen

Es gibt eine Ausprägung von Kohäsion, die deutlich leichter zu fassen ist und die bei Stevens, Myers und Constantine als höchster Grad von Kohäsion beschrieben wird: die funktionale Kohäsion. Dabei handelt es sich um das Maß, in dem die Elemente einer Komponente demselben Zweck im Systemkontext dienen.

Der Zweck einer Komponente beantwortet die Frage: Wozu gibt es die Komponente? Idealerweise lassen sich für jede Komponente Beschreibungen finden, die diesen Zweck eingrenzen. Stevens, Myers und Constantine beschreiben in ihrem Artikel Kriterien dafür, wie man anhand dieser Beschreibungen einschätzen kann, dass eine Komponente keine hohe funktionale Kohäsion besitzt. Diese Kriterien wollen wir noch etwas genauer beleuchten.

Komponenten mit verschiedenen Zwecken

Mehrere Sätze, Wörter wie „und", Kommas oder mehrere Verben deuten darauf hin, dass die Komponente verschiedenen Zwecken dient und somit aufgeteilt werden könnte. In diesem Fall sollte man die Komponente vermutlich in mehrere Teile aufteilen. Das ist etwas elementar Anderes als die Betrachtung der Modularisierung auf einer anderen Flughöhe:

Beispielsweise könnte ein Lohnabwicklungssystem aus verschiedenen Komponenten bestehen: einer Lohnberechnungskomponente, die den auszuzahlenden Nettolohn für jede:n Mitarbeiter:in berechnet, einer Gehaltsauszahlungskomponente, die die Auszahlung veranlasst, und einer Steuermeldungskomponente, die die einbehaltenen Lohnsteuerbeträge aggregiert und ans Finanzamt übermittelt. Die Lohnberechnungskomponente wiederum besteht aus einer Komponente zur Bruttoentgeltberechnung, etwa aus Grundgehalt und Bonuszahlungen, sowie einer Komponente für die Bestimmung des Steuer- und Sozialversicherungsabzugs.

Die Komponente zur Lohnberechnung erfüllt im Gesamtsystem einen einzigen Zweck („Nettolohn ermitteln"), der über die Zwecke der Bruttoentgeltberechnung und der Bestimmung der Abzüge hinausgeht. Umgekehrt gäbe es keinen übergeordneten Zweck, wenn die Gehaltsauszahlungs- und die Steuermeldungskomponente zusammengefasst würden. Hier wäre der Zweck dann etwa „Nettolöhne an Mitarbeiter:innen transferieren und Lohnsteuerbeträge ans Finanzamt übermitteln". Diese Zweckbeschreibung wäre ein klarer Hinweis darauf, dass die Komponenten im Gesamtsystem besser getrennt werden sollten.

Dieses Prinzip ist auch entscheidend für die Heuristik, dass hohe Kohäsion niedrige Kopplung impliziert: Im Beispiel haben sowohl die Lohnberechnungskomponente als Ganzes als auch ihre beiden Unterkomponenten hohe Kohäsion. Auf der Ebene der Unterkomponenten besteht aber Kopplung zwischen ihnen. Die Heuristik gilt jeweils nur auf der Ebene, auf der die Kohäsion betrachtet wird.

Zeitliche Abhängigkeiten

Wenn die Beschreibungen Wörter mit Bezug auf Zeit wie „zuerst", „dann", „nachdem" etc. enthalten, deutet das darauf hin, dass die Elemente der Komponente lediglich zum gleichen Zeitpunkt ausgeführt werden und nicht einem gemeinsamen fachlichen Zweck dienen, genauso wie „Initialisierung", „Aufräumen" etc.

Das klassische Beispiel sind Initialisierungskomponenten: Eine Komponente, die „nachdem das System gestartet wurde, zuerst die Datenbankverbindung aufbaut, die Konfiguration lädt und dann den Benachrichtigungsdienst startet", fasst Dinge zusammen, weil sie alle beim Start passieren, nicht weil sie fachlich zusammengehören. Die entsprechenden Aufgaben sollten aber besser in den Komponenten passieren, die für die relevante Fachlichkeit verantwortlich sind. Das hat den positiven Nebeneffekt, dass Koordination zwischen den Komponenten (wie etwa zeitliche Abhängigkeiten) explizit modelliert wird und nicht implizit in der Reihenfolge der Aufrufe liegt.

Fehlendes spezifisches Objekt

Das dritte Kriterium betrifft die Spezifität der Beschreibung: Wenn das Objekt im Satz sehr allgemein gehalten ist, etwa durch Wörter wie „alle", „jede Art von" oder „sämtliche", deutet das darauf hin, dass die Komponente verschiedene Aufgaben nicht nach fachlichen, sondern nach technischen Kriterien zusammenfasst.

Stevens, Myers und Constantine nennen als Beispiel „Edit All Data" im Gegensatz zu „Edit Source Statement": Das erste fasst alle Datenvalidierungen zusammen, weil sie technisch ähnlich sind; das zweite beschreibt eine einzige, klar umrissene Funktion.

Gute Beschreibungen

Gute Beschreibungen zu finden, geht allerdings über die genannten Kriterien hinaus: Gute Beschreibungen für Komponenten sollten so sein, dass im Systemkontext klar wird, in welcher Komponente sich spezifische Funktionalität einordnen lässt. Sie sollten kurz und möglichst ohne technisches Detailwissen verständlich sein. Damit verhindert man nicht nur niedrige Kohäsion in den einzelnen Komponenten, sondern auch hohe Kopplung durch zusammengehörige Funktionalität, die auf mehrere Komponenten verteilt wird.

Gute Beschreibungen reduzieren mentale Last, indem sich Entwickler:innen im Regelfall nur auf einen begrenzten Teil des Systems beschränken können. Sie verbessern die Verständlichkeit des Codes und die Erweiterbarkeit des Systems, da klarer ist, welcher Teil des Systems welche Funktionalität beinhalten sollte. Das ist insbesondere bei einer hohen Flughöhe mit komplexen Systemen relevant, wenn etwa verschiedene Teams für die verschiedenen Komponenten verantwortlich sind. Gute Beschreibungen zu finden, ist schwer und zeitaufwändig, lohnt sich aber langfristig.

Kopplung und Kohäsion

Abgrenzung

Im Gegensatz zu Kopplung bezieht sich Kohäsion immer nur auf eine einzige Komponente im Systemkontext. Nehmen wir als Beispiel ein Content-Management-System mit einer Artikel-Komponente, die Artikel verwaltet, und einem URL-Router, der URLs auf Inhalte abbildet. Als neues Feature sollen Slugs für Artikel aus Titel und Metadaten generiert werden (aus „Mein Artikel" wird „mein-artikel-2026–06–24"). Da die Slugs in URLs vorkommen, entscheidet das Entwicklungsteam, die Logik im URL-Router zu implementieren.

Fachlich betrachtet ist ein Slug aber eine Eigenschaft des Artikels. Er leitet sich aus Titel und Metadaten ab und ergibt außerhalb des Artikel-Kontexts keinen Sinn. Die Kohäsion der Artikel-Komponente ist dadurch, dass die Logik im URL-Router liegt, allerdings nicht schlechter geworden: Die Komponente selbst hat sich nicht verändert.

Was sich dagegen ändert, ist die Kopplung: Der URL-Router muss nun direkt auf Titel und Metadaten der Artikel zugreifen. Hätte man die Slug-Generierung in der Artikel-Komponente implementiert, würde der URL-Router stattdessen einfach artikel.slug() aufrufen, und die Abhängigkeit wäre auf eine einzelne Methode beschränkt.

Also: Kohäsion beschreibt nur, wie sehr Dinge innerhalb einer Komponente zusammenhängen. Funktionalität, die fachlich in eine Komponente gehört, aber woanders implementiert wird, verschlechtert die Kohäsion dieser Komponente nicht, erhöht aber typischerweise die Kopplung zwischen den betroffenen Komponenten.

Impliziert hohe Kohäsion niedrige Kopplung?

Die ursprüngliche Motivation hinter der Einführung von Kohäsion war, dass es einfacher ist, Kohäsion zu erhöhen, als Kopplung zu verringern, da man nur eine Komponente auf einmal betrachten muss, während Kopplung sich immer auf die Interaktion zwischen Komponenten bezieht.

Die Heuristik lässt sich so begründen, dass Schnittstellen einer hochkohäsiven Komponente schlanker und einfacher gehalten werden können, wenn der Zweck der Komponente klarer beschrieben und eingegrenzt werden kann.

Fazit

Nach dieser Analyse könnte man Kohäsion so definieren: Eine Komponente hat hohe Kohäsion, wenn alle ihre Elemente demselben klar beschreibbaren Zweck im Systemkontext dienen.

Das Entscheidende ist der Zusatz „im Systemkontext": Kohäsion ist kein absolutes Maß, sondern immer relativ zu den Qualitätszielen, die man mit der Modularisierung verfolgt. Verständlichkeit, Änderbarkeit und Wiederverwendbarkeit können unterschiedliche Formen von „Zusammenhang" begünstigen. Die Definition oben entspricht letztlich dem Spezialfall der funktionalen Kohäsion von Stevens, Myers und Constantine, der stärksten Form von Kohäsion.

Die wichtigste praktische Konsequenz: Gute Komponentenbeschreibungen sind kein Nice-to-have, sondern das eigentliche Werkzeug für hohe Kohäsion, wie auch Michael Plöd [6] schreibt. Wer eine Komponente in einem Satz klar und ohne „und" beschreiben kann, hat sehr wahrscheinlich eine kohäsive Komponente.

1. Yourdon, E., & Constantine, L. L. (1979). „Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design". Pearson Education.  ↩︎

2. Bass, L., Clements, P., & Kazman, R. (2012). „Software Architecture in Practice". Addison-Wesley Professional.  ↩︎

3. Dijkstra, E. W. (1968). „The Structure of the 'THE’-Multiprogramming System". Communications of the ACM, 11(5), 341–346. https://doi.org/10.1145/363095.363143  ↩︎

4. Parnas, D. L. (1972). „On the criteria to be used in decomposing systems into modules". Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623  ↩︎

5. Stevens, W. P., Myers, G. J., & Constantine, L. L. (1974). „Structured Design". IBM Systems Journal, 13(2), 115–139. https://doi.org/10.1147/sj.132.0115  ↩︎

6. Plöd, M. (2025). „Bounded Contexts Are All About Cohesion". https://www.michael-ploed.com/blog/bounded-contexts-are-all-about-cohesion. Abgerufen am 25.06.2026  ↩︎