Designprinzipien und Grundlagen

Willkommen zu Kapitel 3: Designprinzipien und Grundlagen. Jede Architektur baut auf denselben wenigen Ideen über Struktur auf. Wie man ein System in Teile zerlegt, wie viel diese Teile voneinander wissen sollten, wohin ihre Abhängigkeiten zeigen sollten und wie man das Ganze so einfach hält, wie das Problem es erlaubt. Dieses Kapitel vermittelt diese Ideen.

Kapitel 2 hat die Qualitäten beschrieben, die eine Architektur liefern muss. Die meisten davon, allen voran die Änderbarkeit, hängen weniger von einer bestimmten Technologie ab als von der Struktur. Ein Team kann das angesagteste Framework wählen und trotzdem ein System bekommen, in dem jede Änderung zehn Stellen berührt. Diese Prinzipien sind alte Ideen. Information Hiding stammt aus dem Jahr neunzehnhundertzweiundsiebzig, das Gesetz von Conway aus dem Jahr neunzehnhundertachtundsechzig. Sie haben überdauert, weil sie etwas beschreiben, das sich nicht ändert: Die Kosten einer Änderung hängen davon ab, wie weit sie sich ausbreiten muss. Geändert hat sich die Ebene. Das Prinzip, das Ihnen rät, die Felder einer Klasse privat zu halten, rät Ihnen auch, die Datenbank eines Service privat zu halten. Deshalb zeigt jeder Abschnitt jede Idee zweimal: in einem kleinen Stück Code und auf der Ebene von Komponenten und Services.

Dieses Kapitel eignet sich für Entwicklungsteams, die präzise über Design nachdenken wollen. Es eignet sich auch für Architekturfachleute, die ein gemeinsames Vokabular für Design-Reviews brauchen. Es hilft, kurze Python-Beispiele lesen zu können. Es baut auf den Qualitätsmerkmalen aus Kapitel 2 auf, die diese Prinzipien erreichen helfen. Es lohnt sich, Abschnitt null Punkt drei über das Organisieren von Code und Abschnitt zwei Punkt sechs über das Design für Veränderung gelesen zu haben. Und es führt zu Kapitel 4, das zeigt, wie man eine Struktur so beschreibt, dass andere sie verstehen und hinterfragen können.

Die ersten vier Abschnitte legen die Grundlagen. Abschnitt drei Punkt eins fragt, was ein Modul ist und wo seine Grenzen verlaufen sollten. David Parnas zeigte, dass eine Zerlegung nach Verarbeitungsschritten scheitert und eine Zerlegung nach wahrscheinlichen Änderungen gelingt. Abschnitt drei Punkt zwei liefert Ihnen das Vokabular, um Grenzen zu beurteilen: die klassischen Stufen von Kopplung und Kohäsion und die Arten von Kopplung, die nur zwischen Services auftreten. Abschnitt drei Punkt drei betrachtet die Schnittstelle selbst: Information Hiding, Verträge, Abstraktionen, die lecken, und warum sich am Ende jemand auf jedes sichtbare Verhalten einer populären Schnittstelle verlässt. Abschnitt drei Punkt vier wendet sich der Richtung zu: wohin Abhängigkeiten zeigen sollten, wie man Stabilität misst, wie man Zyklen auflöst und wie man all das automatisch prüft.

Dieses Diagramm aus Abschnitt drei Punkt zwei zeigt das Vokabular in einem echten Refactoring bei der Arbeit. Links sehen Sie das Design vorher: ein Bestellmodul und ein Abrechnungsmodul. Das Bestellmodul ruft das Abrechnungsmodul direkt auf und übergibt ein Flag, das eines von zwei Verhalten auswählt. Das Bestellmodul muss also dieses Flag kennen und kann keine Bestellung annehmen, wenn die Abrechnung langsam ist oder ausfällt. Schlimmer noch: Beide Module nutzen dieselbe Bestelltabelle. Jede Änderung an ihrem Aufbau, ihren Statuscodes oder ihren Mehrwertsteuerregeln muss in beiden Modulen gleichzeitig erfolgen. Rechts sehen Sie das Design nachher. Das Bestellmodul veröffentlicht ein OrderPlaced-Ereignis an einen Message Broker, das genau die Fakten enthält, die die Abrechnung braucht. Die Abrechnung abonniert es, und jeder Service besitzt seine eigenen Daten. Die Kopplung ist nicht verschwunden: Die Abrechnung hängt weiterhin von der Bedeutung dieses Ereignisses ab. Aber sie ist jetzt explizit, schmal und versioniert, und genau das bedeutet lose Kopplung in der Praxis.

Die zweiten vier Abschnitte bauen auf diesen Grundlagen auf. Abschnitt drei Punkt fünf behandelt die fünf SOLID-Prinzipien, jeweils im Code und zwischen Services gezeigt, zusammen mit der Kritik, die sie bei mechanischer Anwendung auf sich ziehen. Abschnitt drei Punkt sechs führt Connascence ein, ein feineres Maß für Kopplung, mit klaren Regeln, wie man sie schwächer und lokaler macht. Abschnitt drei Punkt sieben weitet den Blick auf die Organisation: das Gesetz von Conway, die Belege dafür und die Arithmetik der Kommunikationspfade. Abschnitt drei Punkt acht schließt mit Einfachheit und Messung: der Komplexität, die zum Problem gehört, und der, die wir selbst hinzufügen, dem Preis offener Optionen und den Grenzen aller Metriken.

Hier ist das Gesetz von Conway in einem Bild. Links sehen Sie eine Organisation. Ein Checkout-Team und ein Katalogteam müssen für jede Schemaänderung über ein gemeinsames Team von Datenbankadministratoren gehen. Rechts sehen Sie das System, das sie bauen: einen Checkout-Service und einen Katalogservice, die beide eine gemeinsame Datenbank lesen und schreiben. Die Struktur des Systems bildet die Struktur der Kommunikation nach. Wenn Sie also ein System entwerfen, entwerfen Sie auch, wer mit wem reden muss, und umgekehrt gilt das genauso.

Zusammen gelesen ergeben die acht Abschnitte ein einziges Argument. Änderungen sind der dominierende Kostenfaktor von Software, also ist eine gute Struktur eine, in der wahrscheinliche Änderungen lokal bleiben. Jedes Prinzip in diesem Kapitel ist ein Weg, das zu erreichen. Deshalb geraten die Prinzipien auch manchmal in Konflikt, und keines gilt absolut. Die professionelle Fähigkeit besteht darin, für eine in diesem System wahrscheinliche Änderung zu fragen, wie weit sie sich ausbreiten müsste und welches Prinzip diese Strecke am günstigsten verkürzt.

Wenn Design neu für Sie ist, lesen Sie die Abschnitte der Reihe nach. Jeder beginnt mit einer kurzen Erklärung aus dem Alltag. Das ganze Kapitel zu lesen dauert etwa drei Stunden. Wenn Sie erfahren sind, beginnen Sie vielleicht lieber mit den ausgearbeiteten Beispielen, etwa dem Onlineshop in Abschnitt drei Punkt eins oder der Metrikberechnung in Abschnitt drei Punkt vier. Sie sind dafür gedacht, dass man darüber streitet. Jeder Abschnitt endet mit einigen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie nachsehen. Wenn Sie so weit sind, machen Sie den optionalen Kapiteltest: zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten in etwa fünfundvierzig Minuten. Die Bestehensgrenze liegt bei achtzig Prozent.

Das ist die Landkarte von Kapitel 3. Beginnen Sie mit Abschnitt drei Punkt eins über Modularität, wo wir sehen, wie man ein System so zerlegt, dass die erwarteten Änderungen in einem Teil bleiben. Bis gleich.