Modularität: ein System in Teile zerlegen

Was ein Modul ist

Ein Modul ist ein Teil eines Systems mit einer klaren Verantwortlichkeit und einer festgelegten Art, wie andere Teile es nutzen. Diese Definition ist bewusst unabhängig von der Größe. In Abschnitt 0.3 war ein Modul eine Python-Datei; in diesem Kapitel umfasst das Wort jede Einheit der Zerlegung, also des Aufteilens eines Systems in Teile: eine Funktion, eine Klasse, ein Paket, eine Bibliothek, eine Komponente innerhalb einer Anwendung oder einen separat deployten Service. Auf jeder Ebene stellen sich dieselben Fragen: Wofür ist dieser Teil verantwortlich, was bietet er anderen an, was behält er für sich, und wovon hängt er ab?

Jedes Modul hat zwei Gesichter. Seine Schnittstelle ist das, was andere Module wissen müssen, um es zu nutzen: Funktionsnamen und Parameter, eine HTTP-API, die Ereignisse, die es veröffentlicht, und auch die informellen Zusagen, etwa wie schnell es antwortet und welche Fehler es zurückgeben kann. Seine Implementierung ist alles andere: der Code, die Datenstrukturen, die Datenbanktabellen, die Drittanbieter-Bibliotheken, die es zufällig verwendet. Gute Modularität hält die Schnittstelle klein und stabil und lässt die Implementierung sich frei ändern.

David Parnas, dessen Artikel von 1972 die Grundlage dieses Abschnitts ist, definierte ein Modul als Zuweisung einer Verantwortlichkeit statt als Stück Programmtext. Für Architekturfachleute ist das die nützlichste Sichtweise. Ein Modul ist ein Versprechen, dass ein Teil des Systems, und meist ein Team, für eine bestimmte Menge von Entscheidungen verantwortlich ist. Ob der Code am Ende in einer Datei oder in vierzig liegt, in einem Prozess oder in zehn, ist eine separate Frage, die weiter unten unter logischen und physischen Modulen behandelt wird.

Warum überhaupt modularisieren

Ein System aus ein paar hundert Zeilen lässt sich als Ganzes verstehen. Ein System aus ein paar Millionen Zeilen nicht, und auch die Organisation, die es baut, kann nicht als eine ungeteilte Gruppe arbeiten. Modularität ist die Eigenschaft, in Module gegliedert zu sein, die sich weitgehend für sich allein verstehen, ändern und durchdenken lassen. Sie ist eines der fünf Teilmerkmale der Wartbarkeit in ISO/IEC 25010 (Abschnitt 2.6) und unterstützt mindestens fünf verschiedene Vorteile.

Verständlichkeit. Eine Entwicklerin oder ein Entwickler kann ein Modul und seine Schnittstellen studieren, ohne den Rest des Systems zu lesen. Parallele Arbeit. Teams können gleichzeitig an verschiedenen Modulen arbeiten und müssen sich kaum abstimmen, weil sie die Schnittstellen vorab vereinbart haben. Isolierung von Änderungen. Eine Änderung an einer Designentscheidung, etwa welche Steuerregeln gelten, erfolgt in einem Modul und breitet sich nicht nach außen aus. Wiederverwendung. Ein gut abgegrenztes Modul, etwa eine Komponente zur Adressvalidierung, kann von mehreren Produkten genutzt werden. Tests. Ein Modul mit einer klaren Schnittstelle lässt sich für sich allein testen, wobei seine Abhängigkeiten durch Test Doubles ersetzt werden.

Parnas nannte 1972 drei davon: den organisatorischen Vorteil (kürzere Entwicklungszeit, weil getrennte Gruppen mit wenig Kommunikation an getrennten Modulen arbeiten), Flexibilität (drastische Änderungen an einem Modul, ohne andere zu ändern) und Verständlichkeit (das System Modul für Modul studieren). Ein halbes Jahrhundert später sind das immer noch die Gründe. Beachten Sie aber, dass keiner davon automatisch daraus folgt, dass man ein System in Stücke schneidet. Ein System kann in fünfzig Module gegliedert sein und trotzdem keinen dieser Vorteile liefern, wenn jede Änderung zehn davon berührt. Die Vorteile hängen ganz davon ab, wo die Grenzen gezogen werden.

Parnas und das KWIC-Beispiel

Parnas veranschaulichte das an einem kleinen Programm namens KWIC (Key Word in Context), das einen Index von Titeln erzeugt. Es liest Textzeilen ein, erzeugt jede zyklische Verschiebung jeder Zeile (indem es wiederholt das erste Wort ans Ende stellt), sortiert alle Verschiebungen alphabetisch und gibt sie aus. Die Zeile Design of Software ergibt Design of Software, of Software Design und Software Design of, sodass eine Leserin oder ein Leser den Titel unter jedem seiner Wörter finden kann.

Die erste Zerlegung, die er beschreibt, ist die, die die meisten Programmierenden beim Zeichnen eines Flussdiagramms erzeugen würden: ein Eingabemodul, das die Zeilen liest und in einem gepackten Format im Speicher ablegt, ein Modul für die zyklische Verschiebung, das einen Index der Startpositionen jeder Verschiebung aufbaut, ein Alphabetisierungsmodul, das diesen Index sortiert, ein Ausgabemodul, das das Ergebnis ausgibt, und ein Hauptsteuermodul, das sie der Reihe nach aufruft. Das ist ein völlig vernünftiges Design. Jedes Modul ist klein, und die Schnittstellen zwischen ihnen sind die Datenformate im Speicher.

Die zweite Zerlegung wirkt seltsamer. Sie hat ein Zeilenspeichermodul, das Funktionen wie liefere das Zeichen in Zeile r, Wort w, Position c anbietet und verbirgt, wie die Zeilen tatsächlich gespeichert sind; ein Eingabemodul, das Zeilen liest und an den Zeilenspeicher übergibt; einen zyklischen Verschieber, der die Verschiebungen über ähnliche Zugriffsfunktionen so präsentiert, als ob sie gespeichert wären; einen Alphabetisierer, der gib mir die i-te Verschiebung in der Reihenfolge anbietet, ohne zu sagen, wann oder wie er sortiert; ein Ausgabemodul und eine Hauptsteuerung. Die Module entsprechen nicht mehr den Schritten der Verarbeitung.

Parnas listete dann Entscheidungen auf, die fragwürdig waren und sich wahrscheinlich ändern würden: das Eingabeformat; alle Zeilen im Speicher zu halten, was bei sehr großen Eingaben unpraktikabel ist; mehrere Zeichen in jedes Maschinenwort zu packen; einen Index der Verschiebungen statt der Verschiebungen selbst zu speichern; und alles einmal zu sortieren, statt bei Bedarf zu suchen. In der ersten Zerlegung betreffen die meisten dieser Änderungen mehrere Module, weil jedes Modul die gemeinsamen Datenformate kennt. In der zweiten bleibt jede Änderung auf das eine Modul beschränkt, das diese Entscheidung verbirgt. Das zweite Design ließ sich auch leichter parallel entwickeln, weil sich die Teams nur auf Funktionsnamen und Parameter einigen mussten, nicht auf detaillierte Tabellenlayouts, und es ließ sich leichter Modul für Modul verstehen.

Das Kriterium: nach Entscheidungen zerlegen, die sich wahrscheinlich ändern

Parnas kam zu dem Schluss, dass es fast immer falsch ist, die Zerlegung eines Systems auf der Grundlage eines Flussdiagramms zu beginnen. Stattdessen schlug er vor, mit einer Liste schwieriger Designentscheidungen oder solcher, die sich wahrscheinlich ändern, zu beginnen und jedes Modul so zu entwerfen, dass es eine solche Entscheidung vor den anderen verbirgt. Er nannte das Prinzip Information Hiding; Abschnitt 3.3 behandelt es ausführlich.

Die Idee klingt einfach, kehrt aber den Instinkt der meisten von uns um. Ein Flussdiagramm beschreibt Zeit: Erst passiert dies, dann das. Designentscheidungen liegen quer zur Zeit. Die Entscheidung, wie eine Bestellung dargestellt wird, spielt eine Rolle, wenn die Bestellung eingeht, bepreist, bezahlt, gespeichert und bestätigt wird. Folgen die Module den Schritten, ist diese eine Entscheidung über alle verteilt, und wer sie ändert, muss alle ändern. Besitzt ein Modul die Entscheidung, fragen alle Schritte dieses Modul, und die Entscheidung lässt sich an einer Stelle ändern.

In der Praxis kommt es auf zwei Präzisierungen an. Erstens geht es beim Kriterium um wahrscheinliche Änderungen; Architekturfachleute müssen also eine fundierte Vermutung über die Zukunft anstellen: Was hat sich in ähnlichen Systemen geändert, was plant das Unternehmen, welche Lieferanten und Vorschriften sind instabil? Die vier Fragen zur Änderbarkeit aus Abschnitt 2.6 (was ändert sich, wie wahrscheinlich, wer ändert es, zu welchen Kosten) liefern genau die Eingaben, die dafür nötig sind. Zweitens unterschied Parnas eine gute Zerlegung von einer Hierarchie. Ein System kann sauber geschichtet und trotzdem schlecht zerlegt sein, und umgekehrt; Abschnitt 3.4 behandelt die Richtung von Abhängigkeiten gesondert.

Logische und physische Module

Ein logisches Modul ist eine Verantwortungseinheit im Design: Katalog, Bestellungen, Zahlungen. Ein physisches Modul ist eine Einheit, die gebaut, versioniert oder deployt wird: eine Java-JAR-Datei, ein Python-Wheel, ein npm-Paket, ein Container-Image, eine Serverless-Funktion. Abschnitt 1.1 nannte diese Modulstrukturen und Zuordnungsstrukturen. Beide hängen zusammen, sind aber nicht dasselbe, und wer sie verwechselt, begeht einige der teuersten Fehler moderner Architektur.

Dasselbe logische Design lässt sich auf sehr unterschiedliche Weise auf physische Module abbilden. Alle logischen Module können in einer deploybaren Einheit leben und sich prozessintern gegenseitig aufrufen: ein modularer Monolith. Oder jedes kann als eigener Service deployt werden und die anderen über das Netzwerk aufrufen: Microservices. Die logischen Grenzen und die Entscheidungen, die jedes Modul verbirgt, können in beiden Fällen identisch sein. Was sich ändert, sind die Kosten, eine Grenze zu überqueren (ein Funktionsaufruf dauert Nanosekunden, ein Netzwerkaufruf Millisekunden und kann fehlschlagen), die Möglichkeit, Teile unabhängig zu releasen und zu skalieren, und der Betriebsaufwand.

Ein häufiger und kostspieliger Fehler ist es, physische Trennung so zu behandeln, als würde sie logische Modularität schaffen. Wer ein schlecht zerlegtes System in Services aufteilt, verbirgt damit keine einzige Entscheidung; er macht aus prozessinternen Aufrufen zwischen verflochtenen Modulen Netzwerkaufrufe zwischen verflochtenen Services, was manchmal als verteilter Monolith bezeichnet wird. Auch der umgekehrte Fehler kommt vor: Ein Team behält eine deploybare Einheit, lässt aber ihre internen Module ineinanderwachsen, sodass es sie später nie mehr trennen kann. Der praktische Rat vieler Fachleute lautet, zuerst die logischen Grenzen richtig zu ziehen, sie durchzusetzen und erst dann zu entscheiden, welche davon es verdienen, zu physischen Grenzen zu werden.

Granularität und ihre Kosten

Wie groß sollte ein Modul sein? Granularität ist die Größe von Modulen im Verhältnis zum System, und es gibt keine allgemeingültige richtige Antwort, weil die Kosten in entgegengesetzte Richtungen ziehen. Größere Module haben weniger Schnittstellen, die man entwerfen und pflegen muss, aber jedes enthält mehr voneinander unabhängige Änderungsgründe, mehr Personen, die gleichzeitig daran arbeiten, und mehr, was man verstehen muss, bevor man etwas ändert. Kleinere Module sind jeweils leichter zu verstehen, aber das System hat mehr Schnittstellen, mehr Abhängigkeiten, die verwaltet werden müssen, und mehr Stellen, an denen ein einzelnes Feature zusammengeflickt werden muss.

Die Kosten einer Schnittstelle hängen auch von der Art der Grenze ab. Zwischen zwei Klassen in einem Programm kostet eine zusätzliche Schnittstelle ein wenig Lesezeit. Zwischen zwei Services kostet sie einen Netzwerksprung, Serialisierung, eine Versionierungsrichtlinie, Monitoring, eine Ausfallart und möglicherweise die Zustimmung eines zweiten Teams zu jeder Änderung. Deshalb ist die richtige Granularität für Services meist viel gröber als die richtige Granularität für Klassen.

Modulgrenzen im Code durchsetzen

Eine Grenze, die nur in einem Diagramm existiert, übersteht keinen Termindruck. Früher oder später importiert jemand eine interne Klasse, weil es schneller geht, und sobald es eine Abkürzung gibt, folgen weitere; Abschnitt 1.7 nannte das Erosion. Sprachen und Build-Werkzeuge bieten mehrere Möglichkeiten, die beabsichtigte Grenze zum Weg des geringsten Widerstands zu machen oder dafür zu sorgen, dass ihr Überschreiten den Build scheitern lässt.

Python setzt auf Konventionen: Namen mit führendem Unterstrich gelten als intern (PEP 8), und die __init__.py eines Pakets kann nur seine öffentlichen Funktionen re-exportieren. Nichts verhindert einen Import von shop.payments._stripe_client, daher setzen Teams, denen das wichtig ist, ein Prüfwerkzeug wie import-linter ein, das den Build scheitern lässt, sobald ein verbotener Import auftaucht. Java bietet Package-private-Sichtbarkeit (der Standard, wenn kein Modifizierer angegeben ist) und seit Java 9 im Jahr 2017 das Java Platform Module System: Eine Datei module-info.java deklariert, welche Module dieses Modul benötigt (requires) und welche seiner Pakete es exportiert (exports); nicht exportierte Pakete lassen sich von außen nicht nutzen, weder zur Kompilierzeit noch zur Laufzeit. Go behandelt jedes Paket unterhalb eines Verzeichnisses namens internal so, dass es nur von Code importiert werden kann, der im übergeordneten Verzeichnis dieses Verzeichnisses wurzelt. C# hat internal, sichtbar nur innerhalb einer Assembly; Rust hat pub(crate).

# shop/payments/__init__.py  (the public face of the package)
from shop.payments.api import charge, refund, PaymentResult

__all__ = ["charge", "refund", "PaymentResult"]

# shop/payments/_provider_client.py   internal: leading underscore
# shop/payments/_retry.py             internal
# shop/payments/api.py                the only module callers should use

# Elsewhere in the shop:
from shop.payments import charge          # fine
from shop.payments._retry import backoff  # works, but breaks the boundary

// module-info.java for the payments module
module shop.payments {
    requires shop.orders.api;        // what this module depends on
    exports shop.payments.api;       // the only package others can use
    // shop.payments.provider and shop.payments.retry are not exported,
    // so code in other modules cannot compile against them
}

Häufige Fehler

Nur nach technischen Schichten zerlegen. Ordner namens controllers, services und repositories sind gewissermaßen Module, aber eine Änderung an der Mehrwertsteuerberechnung berührt alle drei. Schichten sind nützlich (Abschnitt 3.4), doch eine Zerlegung, die nur aus Schichten besteht, ist ein verkapptes Flussdiagramm. Die meisten ausgereiften Systeme kombinieren eine Aufteilung nach Geschäftsfähigkeiten mit Schichtenbildung innerhalb jedes Teils.

Alles gemeinsam nutzen. Ein Modul namens common oder utils, das jedes andere Modul importiert, wird zu dem Ort, an dem sich voneinander unabhängige Entscheidungen ansammeln, und jede Änderung daran breitet sich überallhin aus. Grenzen ohne Durchsetzung. Diagramme zeigen saubere Module, während der Code Hunderte von Querimporten enthält. Module, die durch das Organigramm einer früheren Umstrukturierung definiert sind statt durch die Entscheidungen, die das System verbergen muss; Abschnitt 3.7 erklärt, warum Organisationen und Modulgrenzen aneinander ziehen. Verfrühte Verteilung. Wer jedes logische Modul zu einem Service macht, bevor sich die Grenzen als stabil erwiesen haben, macht spätere Grenzkorrekturen teuer.

Wie Fachleute Modularität anwenden

Erfahrene Architekturfachleute behandeln die Modulstruktur als das wichtigste Designartefakt für die Wartbarkeit, und sie überprüfen sie immer wieder. Früh im Lebenszyklus eines Produkts, wenn die Domäne noch wenig verstanden ist, bevorzugen sie weniger, größere Module mit starken internen Grenzen, weil das Zusammenführen und Aufteilen von Modulen innerhalb einer Codebasis billig ist. Wenn sich die Domäne stabilisiert und wahrscheinliche Änderungen klar werden, verfeinern sie die Grenzen und überlegen erst dann, welche davon separat deployt werden sollten. Techniken aus dem Domain-Driven Design, etwa Bounded Contexts, helfen, Grenzen zu finden, die der Sprache des Fachbereichs folgen.

Sie messen auch. Wer die Module zählt, die von jüngsten Änderungen berührt wurden, was mit der Historie der Versionskontrolle leicht geht, sieht, ob die Grenzen funktionieren; Abschnitt 3.8 führt Change Coupling und Hotspots ein. Der nächste Abschnitt, Abschnitt 3.2, liefert das Vokabular, um zu beschreiben, wie gute und schlechte Grenzen aussehen: Kopplung zwischen Modulen und Kohäsion innerhalb von Modulen.