Trennung von Verantwortlichkeiten
Trennung von Verantwortlichkeiten ordnet Aufgaben nach ihren unterschiedlichen Änderungsgründen; jede Verantwortung erhält eine klare Rolle und Schnittstelle. Englisch heißt das Separation of Concerns, ein Begriff von Edsger Dijkstra; auf Klassenebene ist es als Single Responsibility bekannt, das S aus SOLID.
- AblaufKoordiniert die Schrittfolge.
- FachregelnStatus und Übergänge der Zahlung.
- ProtokollKennt nur die externe API.
Einordnung
Warum das wichtig ist
Wenn Ablauf, Fachregeln und Anbieterprotokoll in einem Baustein stecken, zieht jede Änderung die anderen mit. Ein neuer Fehlercode des Anbieters berührt dann den Bestellablauf. Den Zusammenhalt innerhalb einer Aufgabe behandelt Kohäsion.
Dieser Baustein schneidet quer dazu: Fachregel, Ablauf und Technik bekommen jeweils eigene Plätze. Ob die Aufgaben innerhalb eines Platzes zusammengehören, klärt Kohäsion.
Auf einen Blick · Jede Aufgabe mit eigener Rolle
Drei Verantwortlichkeiten der Zahlung
Bei einer Zahlung ändern sich fachliche Statusregeln, der Bestellablauf und die API des Anbieters aus verschiedenen Gründen. Der Shop trennt diese Aufgaben in passende Bausteine.
So liest du das Bild
- Ablauf Der Kasten Bestellablauf im Bereich Anwendung.
- Fachregeln Der Kasten Zahlungsregeln im Bereich Fachlichkeit.
- Protokoll Der Kasten Anbieteradapter im Bereich Technik, der den Zahlungsanbieter aufruft.
Breites Diagramm · bei Bedarf seitlich verschieben
Diagramm als Text lesen
- Bestellablauf: Schrittfolge koordinieren (Anwendung)
- Zahlungsregeln: Status und Übergänge (Fachlichkeit)
- Anbieteradapter: externes Protokoll (Technik)
- Zahlungsanbieter: Autorisierungs-API (Extern)
- Bestellablauf → Zahlungsregeln: Zahlung starten
- Zahlungsregeln → Anbieteradapter: Autorisierung anfordern
- Anbieteradapter → Zahlungsanbieter: API aufrufen
- Anbieteradapter → Zahlungsregeln: Ergebnis übersetzen
Drei Richtungen der Trennung
| Richtung | Was wird getrennt | Im Shop | Vertieft in |
|---|---|---|---|
| Vertikal | fachliche Bereiche | Katalog, Zahlung, Versand | Kohäsion, Modulgrenzen |
| Horizontal | Ablauf, Fachregel, Technik | Bestellablauf, Zahlungsregeln, Anbieteradapter | dieser Baustein, Layered Architecture, Hexagonale Architektur |
| Querschnitt | Belange, die überall gebraucht werden | Logging, Autorisierung, Fehlerbehandlung | Observability, Authentifizierung & Autorisierung, Gateway |
Nutzen & Grenzen
Hilft, wenn
- Änderungen an Darstellung oder Infrastruktur beschädigen wiederholt fachliche Regeln.
- Eine Aufgabe muss unabhängig getestet oder an mehreren Eingangswegen wiederverwendet werden.
Grenzen
- Viele Schichten ohne eigenen Zweck erhöhen Abstimmung und Suchaufwand. Prüfe ihre Verantwortung anhand von Kohäsion und konkreten Änderungspfaden.
- Transaktionen und Fehler können mehrere Concerns zugleich betreffen. Benenne den koordinierenden Ablauf und prüfe seine Modulgrenzen, statt Zusammenhänge zu verbergen.
In der Praxis
- Änderungsgründe erfassen. Trenne fachliche Regeln, technische Anbindung und Darstellung anhand ihrer jeweiligen Änderungsmuster. Das Ergebnis zeigt, welche Aufgaben unabhängig bearbeitet werden können.
- Verantwortungen und Verträge zuordnen. Bestimme, welcher Teil Eingaben annimmt, entscheidet und technische Wirkungen ausführt. Nutze Modulgrenzen, um die Übergänge verbindlich zu beschreiben.
- Zusammenspiel und Fehlerpfad testen. Prüfe einzelne Verantwortungen und den vollständigen Ablauf einschließlich Fehlern. Kohäsion hilft zu beurteilen, ob zusammengehörige Regeln gemeinsam bleiben.
Ausführliche Erklärung lesen
Ein Systemablauf kann Eingabe, fachliche Entscheidung, Speicherung und Darstellung verbinden. Diese Concerns lassen sich an klaren Übergängen getrennt bearbeiten, solange der Gesamtvorgang nachvollziehbar bleibt. Kohäsion bündelt zusammengehörige Aufgaben; Dependency Inversion hält den Fachkern von Infrastruktur abhängigkeitsfrei.
Trennung hilft, wenn Verantwortungen unterschiedlich geändert oder geprüft werden. Sie braucht jedoch eine klare Koordination für Transaktionen, Berechtigungen und Fehlerpfade, die mehrere Teile betreffen können. Eine Schicht trägt durch Übersetzung, Regelprüfung oder Ablaufsteuerung eigene Verantwortung; passive Durchreichschichten fügen Aufwand hinzu. Prüfe Grenzen anhand des Änderungswegs und der Zusammenarbeit, die ein vollständiger Ablauf benötigt.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welcher Baustein ruft die API des Zahlungsanbieters auf?
Lösung mit Begründung ansehen
Der Anbieteradapter, per Kante „API aufrufen“ zum Zahlungsanbieter.
AnwendenAuf eine neue Lage übertragen
Jeder Zugriff auf Bestellung, Zahlung und Versand soll protokolliert werden. Welche Richtung der Trennung ist das, und wo gehört es hin?
Lösung mit Begründung ansehen
Ein Querschnittsthema. Es gehört nicht in jedes Modul einzeln, sondern in einen gemeinsamen Mechanismus, etwa Middleware oder ein Gateway, damit die Fachmodule davon frei bleiben.
BewertenEine Alternative abwägen
Das Team erwägt, Zahlungsregeln und Anbieteradapter zusammenzulegen. Was spricht dafür und dagegen?
Lösung mit Begründung ansehen
Dafür: ein Baustein weniger und kürzere Wege. Dagegen: Fachstatus und Anbieterprotokoll haben verschiedene Änderungsgründe, und ein Anbieterwechsel würde die Regeln berühren.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Edsger W. Dijkstra · On the role of scientific thought (EWD447) (öffnet in neuem Tab)Text von 1974, in dem Dijkstra den Begriff Separation of Concerns prägt.
- Microsoft · Architectural Principles (öffnet in neuem Tab)Erklärt Separation of Concerns, Kapselung und Dependency Inversion.
- Alistair Cockburn · Hexagonal Architecture (öffnet in neuem Tab)Originalbeschreibung von Ports, Adaptern und austauschbaren Außenanbindungen.