Kohäsion
Kohäsion beschreibt den inneren Zusammenhang der Aufgaben eines Bausteins. Hohe fachliche Kohäsion bündelt Regeln, die aus denselben Gründen gemeinsam geändert werden.
- ÄnderungsgrundWas sich zusammen ändert, gehört zusammen.
- Fachlicher SchnittEin Modul trägt eine Fachaufgabe komplett.
- Passendes ModulDie fachlich richtige Heimat jeder Aufgabe.
Einordnung
Warum das wichtig ist
Aufgaben, die aus verschiedenen Gründen geändert werden, gehören nicht zusammen. Wo sie vermischt sind, zieht eine Preisänderung Zahlungscode mit. Wie Aufgaben allgemein getrennt werden, behandelt der Baustein Separation of Concerns.
Dieser Baustein blickt nach innen: Gehört zusammen, was in einem Baustein liegt? Wie Aufgaben auf verschiedene Plätze verteilt werden, behandelt Trennung von Verantwortlichkeiten.
Auf einen Blick · Gemeinsamer Grund, gemeinsames Modul
Schnitt nach Technik oder nach Fachlichkeit?
Preisermittlung, Produktbeschreibung und Sortimentssicht ändern sich aus Kataloggründen. Zahlungsautorisierung und Zahlungsstatus folgen dagegen Regeln der Zahlung.
So liest du das Bild
- Änderungsgrund Die Zahl „Betroffene Module“ im Szenario: Preisregel oder Zahlart zeigt den Grund.
- Fachlicher Schnitt Im Zuschnitt „nach Fachlichkeit“ ändert sich nur Katalog bzw. Zahlung.
- Passendes Modul Die Tabelle darunter: Spalte „Gehört in“ nennt Katalog oder Zahlung.
- ändert sichOberflächePreisanzeige anpassen
- ändert sichGeschäftslogikPreisregel für Tassen einbauen
- ändert sichDatenzugriffPreisfelder und Abfragen erweitern
- nicht vorhandenKataloggibt es in diesem Schnitt nicht
- nicht vorhandenZahlunggibt es in diesem Schnitt nicht
3Betroffene Module
Die Preisregel zieht durch alle drei Schichten, obwohl sie fachlich eine Sache ist.
Werte illustrativ
Welche Aufgabe gehört in welches Modul?
| Aufgabe | Warum ändert sie sich? | Gehört in | Zieht sonst mit |
|---|---|---|---|
| Produktpreis ändern | Sortiment und Preisregel | Katalog | allgemeiner Datenservice |
| Produkttext pflegen | Sortimentsdarstellung | Katalog | Bestellung |
| Zahlung ablehnen | Zahlungsregel | Zahlung | Katalog |
| Zahlungsstatus klären | Anbieterinteraktion | Zahlung | Rechnung |
Nutzen & Grenzen
Hilft, wenn
- Ein Baustein hat mehrere unverbundene Gründe, sich zu ändern.
- Regeln und Daten werden an wechselnden Stellen gesucht und gemeinsam angepasst.
Grenzen
- Gemeinsame Änderungsgründe prägen Kohäsion auch bei kleinen Bausteinen. Prüfe diese Gründe und vermeide Zerlegung, die nur zusätzliche Kopplung erzeugt.
- Ein technischer Sammelbereich kann fachliche Verantwortung verschleiern. Formuliere den Zweck und prüfe, ob Separation of Concerns unterschiedliche Änderungsgründe sichtbar trennt.
In der Praxis
- Änderungsmuster untersuchen. Vergleiche mehrere reale Änderungen und notiere, welche Regeln, Daten und Tests gemeinsam betroffen waren. Das Ergebnis zeigt wiederkehrende Verantwortungszusammenhänge.
- Zweck jedes Bausteins klar formulieren. Beschreibe, welche zusammenhängende Aufgabe er erfüllt und welche Informationen er besitzt. Nutze Modulgrenzen, um diesen Zweck gegenüber Verbrauchern sichtbar zu machen.
- Unabhängige Gründe abgrenzen. Prüfe, ob unterschiedliche Änderungen ohne gemeinsamen fachlichen Grund zusammenliegen. Separation of Concerns hilft, solche Aufgaben zu ordnen, ohne unnötige Übergänge einzuführen.
Ausführliche Erklärung lesen
Ein kohäsiver Baustein bündelt Verhalten und Daten, die aus demselben fachlichen oder technischen Grund verändert werden. Sein Zweck lässt sich klar benennen, und seine internen Teile unterstützen eine zusammenhängende Verantwortung. Separation of Concerns trennt unterschiedliche Änderungsgründe; Modulgrenzen machen die Zuständigkeit nach außen sichtbar.
Kohäsion zeigt sich in realen Änderungsmustern: Welche Regeln, Tests und Daten werden gemeinsam angepasst? Eine rein technische Gruppierung kann unterschiedliche Verantwortungen verdecken; eine zu feine Aufteilung schafft zusätzliche Übergänge. Entscheidend ist ein sinnvoller innerer Zusammenhang, der Änderungen an der passenden Stelle auffindbar hält.
Der Begriff stammt aus dem Structured Design von Larry Constantine, der Kohäsion auf einer Skala einordnete, von schwach nach stark: zufällig, logisch, zeitlich, prozedural, kommunikativ, sequenziell und funktional. Zufällig kohäsiv ist das Sammelmodul „Utils“, in dem Dinge nur zusammenliegen, weil sie sonst nirgends hinpassten. Logisch kohäsiv ist ein Modul, das Verwandtes nach Art der Aufgabe bündelt, etwa alle Ausgabefunktionen, obwohl sie fachlich nichts miteinander zu tun haben. Zeitlich kohäsiv ist „alles, was nachts läuft“: Die Teile verbindet nur der Zeitpunkt. Funktional kohäsiv ist ein Modul, dessen Teile gemeinsam genau eine Aufgabe erfüllen. Ein Hilfsmodul ist schwach kohäsiv, weil seine Teile aus verschiedenen Gründen geändert werden: Jede Änderung berührt dasselbe Modul und kann die anderen Teile mitreißen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Module ändern sich bei der neuen Preisregel im technischen Schnitt?
Lösung mit Begründung ansehen
Drei: Oberfläche, Geschäftslogik und Datenzugriff. Im fachlichen Schnitt ändert sich nur der Katalog.
AnwendenAuf eine neue Lage übertragen
Der Shop braucht eine neue Preisregel für Tassen. Wo wird sie umgesetzt, und was bleibt unberührt?
Lösung mit Begründung ansehen
Im Katalog, denn „Produktpreis ändern“ gehört zu Sortiment und Preisregel. Die Zahlung bleibt davon unberührt.
BewertenEine Alternative abwägen
Soll die Übersetzung des Zahlungsstatus in die Rechnung wandern, weil sie dort gebraucht wird?
Lösung mit Begründung ansehen
Die Rechnung hätte so alles an einem Ort. Der Anbieterstatus ändert sich aber mit der Zahlungsintegration und gehört deshalb zur Zahlung, wie die Matrix zeigt. Die Rechnung liest das übersetzte Ergebnis.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- David Parnas · On the Criteria To Be Used in Decomposing Systems into Modules (öffnet in neuem Tab)Grundlagenpapier zu Information Hiding und stabilen Modulgrenzen. Wissenschaftliche Originalpublikation; der Volltextzugang beim Verlag kann eingeschränkt sein.
- Robert C. Martin · The Single Responsibility Principle (öffnet in neuem Tab)Ein Modul soll einen Grund zur Änderung haben: Was sich aus demselben Grund ändert, gehört zusammen.
- Microsoft · Domain Analysis (öffnet in neuem Tab)Leitet Domänengrenzen und Bounded Contexts aus fachlichen Zusammenhängen ab.