Abhängigkeiten steuern: Richtung, Zyklen und Stabilität

Warum die Richtung zählt

Eine Abhängigkeit besteht, wenn ein Modul ein anderes braucht, um zu kompilieren, zu laufen oder sich korrekt zu verhalten. Zeichnen Sie sie als Pfeil von dem Modul, das abhängt, zu dem Modul, von dem es abhängt: Checkout zu Preisgestaltung. Der Pfeil sagt etwas Wichtiges über Änderungen aus. Ändert die Preisgestaltung ihre Schnittstelle oder ihr Verhalten, muss sich der Checkout womöglich ändern; ändert sich der Checkout, ist das der Preisgestaltung gleich. Änderungen laufen entgegen der Pfeilrichtung. Die Richtung jeder Abhängigkeit ist also eine Entscheidung darüber, wer durch wessen Änderungen gestört wird.

Architekten befassen sich mit zwei Arten von Richtung, die man leicht verwechselt. Der Kontrollfluss ist, wer wen zur Laufzeit aufruft. Die Quellcode-Abhängigkeit ist, wer wen importiert, referenziert oder gegen wen kompiliert. Meist zeigen beide in dieselbe Richtung, aber das muss nicht so sein. Ein Framework ruft Ihren Code auf, ohne von ihm abzuhängen (Abschnitt 0.3 nannte das Inversion of Control), und mit einer Schnittstelle kann ein übergeordnetes Modul ein untergeordnetes aufrufen, während die Quellcode-Abhängigkeit in die andere Richtung zeigt. Diese Freiheit, die Richtung der Quellcode-Abhängigkeit unabhängig vom Kontrollfluss zu wählen, ist das mächtigste Werkzeug dieses Abschnitts.

Zwischen Services zeigt sich Richtung als Wissen. Ruft Bestellungen die API der Abrechnung auf, hängt Bestellungen von der Abrechnung ab und muss sich ändern, wenn sich deren API ändert. Veröffentlicht Bestellungen ein Ereignis, das die Abrechnung konsumiert, kehrt sich die Abhängigkeit um: Die Abrechnung hängt vom Ereignisvertrag von Bestellungen ab, und Bestellungen weiß nicht, dass es die Abrechnung gibt (Abschnitt 3.2). Die Wahl zwischen einem Aufruf und einem Ereignis ist daher teilweise eine Wahl der Abhängigkeitsrichtung.

Das Acyclic Dependencies Principle

Robert C. Martin formulierte drei Prinzipien für Abhängigkeiten zwischen Komponenten, zuerst Mitte der 1990er-Jahre in Artikeln und Aufsätzen und später in Agile Software Development: Principles, Patterns, and Practices (2002) und Clean Architecture (2017). Das erste, das Acyclic Dependencies Principle (ADP), besagt, dass der Abhängigkeitsgraph zwischen Komponenten keine Zyklen enthalten darf: Er muss ein gerichteter azyklischer Graph sein.

Ein Abhängigkeitszyklus wie „Bestellungen hängt von Benachrichtigungen ab, Benachrichtigungen von Kunden und Kunden von Bestellungen“ macht aus drei Komponenten eine. Keine lässt sich ohne die anderen kompilieren oder testen; eine Änderung an einer kann sich durch die Schleife bis zu ihr selbst zurück fortpflanzen; keine kann eigenständig ausgeliefert werden; und niemand kann sagen, welche zuerst zu bauen ist. Martin führt das Prinzip mit dem ein, was er das Morning-after-Syndrom nennt: Sie gehen mit funktionierendem Code nach Hause und stellen am nächsten Tag fest, dass er kaputt ist, weil jemand anderes etwas geändert hat, wovon Sie abhängen. Sein Heilmittel ist, das System in getrennt releaste Komponenten aufzuteilen, und das funktioniert nur, wenn die Abhängigkeiten zwischen ihnen keine Zyklen enthalten. Zyklen machen es außerdem unmöglich, eine Komponente später als Bibliothek oder Service herauszulösen, weil sie die ganze Schleife mitzieht.

Das Java Platform Module System erzwingt ADP zwischen Modulen: Die Java Language Specification macht es zu einem Kompilierfehler, wenn ein Modul direkt oder indirekt von sich selbst abhängt. Die meisten anderen Sprachen erlauben Zyklen zwischen Paketen, daher prüfen Teams sie mit Werkzeugen. Zyklen zwischen Klassen innerhalb einer kleinen Komponente sind weniger schädlich, und unter anderem Martin Fowler toleriert sie dort; am wichtigsten ist das Prinzip zwischen Komponenten, die verschiedene Leute bauen und releasen.

Zyklen auflösen

Jeder Zyklus lässt sich auflösen, und es gibt zwei Standardtechniken. Beide zeigt das Diagramm unten für einen Zyklus, in dem Bestellungen die Benachrichtigungen aufruft, um eine Bestätigung zu senden, und Benachrichtigungen in Bestellungen zurückruft, um die Details der Bestellung zu lesen.

Abhängigkeitsumkehr. Benachrichtigungen deklariert eine Schnittstelle, die genau beschreibt, was es braucht, etwa OrderLookup mit einer Methode, und Bestellungen implementiert sie. Der Pfeil von Benachrichtigungen zu Bestellungen zeigt nun in die andere Richtung: Bestellungen hängt von Benachrichtigungen ab (um es aufzurufen und seine Schnittstelle zu implementieren), und Benachrichtigungen hängt von nichts in Bestellungen ab. Das ist Abhängigkeitsumkehr, die Abschnitt 3.5 als das D in SOLID behandelt. Das entscheidende Detail ist die Eigentümerschaft: Die Schnittstelle gehört dem Modul, das sie nutzt, nicht dem, das sie implementiert.

Eine neue Komponente herauslösen. Finden Sie heraus, was beide Seiten tatsächlich voneinander brauchen, oft ein kleines gemeinsames Modell oder ein Vertrag, und verschieben Sie es in eine neue Komponente, von der beide abhängen. Hier veröffentlicht Bestellungen einen Ereignistyp, der in einer Komponente Bestellereignisse definiert ist, und Benachrichtigungen liest die Bestelldetails aus dem Ereignis, statt zurückzurufen. Von der neuen Komponente hängen beide ab, und sie hängt von keiner ab, ist also stabiler als jede von ihnen: genau das, was das nächste Prinzip verlangt.

Das Stable Dependencies Principle und Instabilität

Manche Komponenten ändern sich oft (Benutzeroberflächen, Integrationen mit Partnern, neue Features); andere sollten sich selten ändern (zentrale Domänenkonzepte, gemeinsame Verträge, der Umgang mit Geld). Das Stable Dependencies Principle (SDP) besagt: Abhängigkeiten in Richtung der Stabilität. Von einer Komponente, die leicht zu ändern sein soll, sollte keine Komponente abhängen, die schwer zu ändern ist, sonst wird sie ebenfalls schwer zu ändern.

Martin misst Stabilität über Abhängigkeiten, nicht darüber, wie oft der Code bearbeitet wird. Eine Komponente, von der viele andere abhängen, ist stabil in dem Sinne, dass sie teuer zu ändern ist: Jede Änderung riskiert, ihre abhängigen Komponenten zu brechen. Eine Komponente, die von vielen anderen abhängt und keine abhängigen Komponenten hat, ist instabil: Nichts hindert sie daran, sich zu ändern, und ihre Abhängigkeiten können sie dazu zwingen. Mit der afferenten Kopplung (Ca, eingehend) und der efferenten Kopplung (Ce, ausgehend) aus Abschnitt 3.2 ist die Instabilität:

I = Ce / (Ca + Ce)

I reicht von 0 bis 1. I = 0 bedeutet nur eingehende Abhängigkeiten: maximal stabil, vielen gegenüber verantwortlich, von nichts abhängig. I = 1 bedeutet nur ausgehende Abhängigkeiten: maximal instabil, nichts hängt davon ab. Als Metrik formuliert besagt das SDP, dass I entlang jedes Abhängigkeitspfeils abnehmen sollte: Jede Komponente sollte von Komponenten mit einem niedrigeren I als ihrem eigenen abhängen. Eine Abhängigkeit von einer stabilen Komponente (I = 0,1) zu einer volatilen (I = 0,8) ist ein Warnsignal; die übliche Lösung ist wiederum Abhängigkeitsumkehr, also eine Schnittstelle an einer stabilen Stelle.

Das Stable Abstractions Principle und die Hauptreihe

Stabilität hat ihren Preis: Eine Komponente mit I nahe 0 ist schwer zu ändern. Besteht sie aus viel konkretem Code, wird das System starr. Das Stable Abstractions Principle (SAP) löst das: Eine Komponente sollte so abstrakt sein, wie sie stabil ist. Stabile Komponenten sollten überwiegend aus Schnittstellen und abstrakten Typen bestehen, damit sich ihr Verhalten durch neue Implementierungen an anderer Stelle erweitern lässt, ohne sie zu ändern; instabile Komponenten dürfen konkret sein, weil sie ohnehin leicht zu ändern sind. SDP und SAP zusammen sind das Dependency Inversion Principle, angewandt auf ganze Komponenten: Abhängigkeiten zeigen zur Stabilität, und Stabilität geht mit Abstraktion einher.

Die Abstraktheit wird gemessen als A = Na / Nc, wobei Na die Zahl der abstrakten Klassen und Schnittstellen in der Komponente ist und Nc die Gesamtzahl der Klassen. A = 0 bedeutet vollständig konkret; A = 1 bedeutet nichts als Abstraktionen. Trägt man A gegen I auf, ergibt sich ein Quadrat. Die Linie von (I = 0, A = 1) bis (I = 1, A = 0) ist die Hauptreihe: stabil und abstrakt an einem Ende, instabil und konkret am anderen, mit ausgewogenen Mischungen dazwischen. Die Distanz zu ihr ist:

D = |A + I - 1|

D reicht von 0 (auf der Linie) bis 1 (in einer entfernten Ecke). Die Ecke nahe (0, 0) ist die Zone des Schmerzes: stabil, weil viel davon abhängt, und konkret, sodass jede Änderung sowohl nötig als auch schmerzhaft ist. Ein Datenbankschema, das jedes Modul direkt liest, liegt hier. Martin merkt an, dass manche Komponenten harmlos dorthin gehören, etwa eine ausgereifte konkrete Hilfsbibliothek, die sich nie ändern muss; die Zone schmerzt nur bei volatilen Komponenten. Die Ecke nahe (1, 1) ist die Zone der Nutzlosigkeit: Abstraktionen, von denen nichts abhängt, typischerweise Schnittstellen, die nach einem Refactoring übrig geblieben sind oder für eine Erweiterung entworfen wurden, die nie kam.

Strikte und gelockerte Schichtenbildung

Schichtenbildung ist die älteste und häufigste Abhängigkeitsregel: Module werden in Schichten angeordnet, etwa Präsentation, Anwendung oder Domäne und Persistenz, und jede Schicht darf nur Schichten unter ihr nutzen. Untere Schichten wissen nichts über höhere, sodass sich eine neue Benutzeroberfläche hinzufügen lässt, ohne die Domäne zu ändern. Schichtenbildung ist ein eigener Architekturstil (Abschnitt 5.2); hier interessiert die Abhängigkeitsregel, die sie vorgibt.

Bei strikter (geschlossener) Schichtenbildung darf jede Schicht nur die unmittelbar darunterliegende Schicht nutzen. Jede Schicht verbirgt dann alles unter ihr, und das Ersetzen einer unteren Schicht betrifft nur eine andere Schicht; der Preis ist durchreichender Code, bei dem die mittlere Schicht bloß Aufrufe weiterleitet, zu denen sie nichts beizutragen hat. Bei gelockerter (offener) Schichtenbildung darf eine Schicht jede Schicht unter ihr nutzen. Das beseitigt den Boilerplate-Code, bedeutet aber, dass eine Änderung an der untersten Schicht jede Schicht darüber betreffen kann. Viele reale Systeme mischen beides und markieren bestimmte Schichten als offen, etwa eine gemeinsame Logging- oder Hilfsschicht, die alle nutzen dürfen.

Die klassische Schichtenbildung hat eine berüchtigte Schwäche: Die Domänenschicht hängt von der Persistenzschicht ab, sodass die wichtigsten Geschäftsregeln von Datenbankdetails abhängen. Hexagonale, Onion- und Clean Architecture (Abschnitt 5.6) wenden Abhängigkeitsumkehr an, um das zu beheben: Die Domäne besitzt Schnittstellen wie OrderRepository, und der Persistenzcode implementiert sie, sodass alle Quellcode-Abhängigkeiten nach innen zur Domäne zeigen.

Abhängigkeitsregeln automatisch prüfen

Abhängigkeitsregeln, die nur in einem Wiki stehen, werden innerhalb von Wochen gebrochen. Der verlässliche Weg, sie einzuhalten, ist, sie als ausführbare Prüfungen zu formulieren, die im Build laufen und ihn fehlschlagen lassen, wenn eine Regel verletzt wird. Eine solche Prüfung ist eine architektonische Fitness Function, eine Idee, die in Abschnitt 2.8 eingeführt und in Abschnitt 11.3 weiterentwickelt wird. Drei weit verbreitete Open-Source-Werkzeuge decken die wichtigsten Ökosysteme ab.

ArchUnit (Java und andere JVM-Sprachen) lässt Sie Architekturregeln als gewöhnliche Unit-Tests schreiben: welche Pakete auf welche zugreifen dürfen, Schichtdefinitionen und Zyklenfreiheit zwischen Teilen der Codebasis. dependency-cruiser (JavaScript und TypeScript) analysiert Importe und prüft sie gegen Regeln in einer Konfigurationsdatei, und seine Startkonfiguration verbietet bereits zirkuläre Abhängigkeiten. import-linter (Python) prüft in einer Konfigurationsdatei deklarierte Contracts; zu seinen Contract-Typen gehören verbotene Importe, Schichten, Unabhängigkeit zwischen benachbarten Modulen, geschützte Module und azyklische Geschwistermodule.

@ArchTest
static final ArchRule layers = layeredArchitecture()
    .consideringAllDependencies()
    .layer("Web").definedBy("..web..")
    .layer("Domain").definedBy("..domain..")
    .layer("Persistence").definedBy("..persistence..")
    .whereLayer("Web").mayNotBeAccessedByAnyLayer()
    .whereLayer("Domain").mayOnlyBeAccessedByLayers("Web", "Persistence")
    .whereLayer("Persistence").mayNotBeAccessedByAnyLayer();

@ArchTest
static final ArchRule noCycles =
    slices().matching("com.shop.(*)..").should().beFreeOfCycles();

// .dependency-cruiser.js
module.exports = {
  forbidden: [
    { name: "no-circular", severity: "error",
      from: {}, to: { circular: true } },
    { name: "domain-not-to-db", severity: "error",
      comment: "Domain code must use repository interfaces, not the database",
      from: { path: "^src/domain" },
      to: { path: "^src/db" } },
  ],
};

# .importlinter
[importlinter]
root_package = shop

[importlinter:contract:layers]
name = Web above domain above adapters
type = layers
layers =
    shop.web
    shop.domain
    shop.adapters

[importlinter:contract:features-independent]
name = Feature packages do not import each other
type = independence
modules =
    shop.catalogue
    shop.ordering
    shop.payments

Beachten Sie, dass die ArchUnit-Regel oben der Persistenz den Zugriff auf die Domäne erlaubt, aber nicht umgekehrt: die eben beschriebene domänenzentrierte Anordnung, nicht die klassische Schichtenbildung. Solche Regeln sind schnell hinzugefügt, laufen in Sekunden und machen aus einem Architekturdiagramm etwas, das der Build verteidigt. Verletzt eine bestehende Codebasis eine Regel bereits, können die meisten Werkzeuge die aktuellen Verstöße als Baseline erfassen und nur bei neuen fehlschlagen, sodass die Regel ab dem Tag ihrer Einführung verhindert, dass es schlimmer wird.

Wie Fachleute Abhängigkeiten steuern

Erfahrene Architekten haben ein Bild des Abhängigkeitsgraphen zwischen Komponenten und sehen es sich regelmäßig an, aus dem Code erzeugt statt von Hand gezeichnet. Sie entscheiden, welche Komponenten stabil sein sollen (Domänenkonzepte, gemeinsame Verträge) und welche volatil (Benutzeroberflächen, Integrationen), und lassen die Pfeile von volatil zu stabil zeigen. Neue Zyklen behandeln sie als Build-Fehler, nicht als Stilfragen. Und sie wenden dasselbe Denken über Services hinweg an: Gemeinsame Bibliotheken und gemeinsame Event-Schemas sind die stabilen Komponenten eines verteilten Systems und verdienen minimale Oberflächen und sorgfältige Versionierung, während die Interna jedes Service frei veränderbar bleiben.

Nichts davon erfordert, dass die Metriken genau berechnet werden. Ihr Wert liegt in den Fragen, die sie erzwingen: In welche Richtung sollte dieser Pfeil zeigen, was passiert mit allem, was davon abhängt, wenn sich das ändert, und ist diese Komponente so abstrakt, wie es die Zahl der Dinge verlangt, die von ihr abhängen? Abschnitt 3.5 geht weiter mit den SOLID-Prinzipien, die dieselben Ideen innerhalb von Komponenten und zwischen ihnen anwenden.