Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 25

Es ist wichtig, die ausgleichenden Kräfte zwischen Kopplung und Kohäsion zu verstehen, wenn Sie die Grenzen von Microservices definieren. Bei der Kopplung geht es darum, dass, sobald wir etwas ändern, etwas anderes ebenfalls geändert werden muss. Bei der Kohäsion geht es darum, wie wir zusammengehörigen Code gruppieren. Diese Konzepte sind direkt miteinander verbunden. Constantines Gesetz drückt diese Beziehung sehr gut aus:

Eine Struktur ist stabil, wenn die Kohäsion stark und die Kopplung schwach ist.

– Larry Constantine

Das scheint eine vernünftige und nützliche Beobachtung zu sein. Haben wir zwei Bereiche eng miteinander verbundenen Codes, ist die Kohäsion gering, da die zusammengehörige Funktionalität über beide Bereiche verteilt ist. Ebenso haben wir eine starke Kopplung, denn wenn sich dieser Code ändert, müssen beide Bereiche angepasst werden.

Ändert sich die Struktur unseres Codesystems, wird das teuer werden, da in verteilten Systemen die Kosten für Änderungen über Servicegrenzen hinweg so hoch sind. Wenn Sie Änderungen über einen oder mehrere unabhängig deploybare Services hinweg vornehmen und dabei vielleicht sogar Serviceverträge brechen müssen, kann das ziemlich aufwendig sein.

Das Problem bei Monolithen ist, dass es allzu häufig das Gegenteil von beidem ist. Statt in Richtung Kohäsion zu tendieren und die Dinge zusammenzuhalten, die zusammengehören sollten, stecken wir allen möglichen unzusammenhängenden Code zusammen. Und lose Kopplung existiert damit auch nicht wirklich: Will ich eine Zeile meines Codes ändern, kann ich das vielleicht noch problemlos tun, aber ich kann diese Änderung nicht deployen, ohne potenziell einen Großteil des restlichen Monolithen zu beeinträchtigen – und ich muss mit Sicherheit das gesamte System neu deployen.

Wir wollen Stabilität auch deshalb, weil unser Ziel wo immer möglich die Umsetzung des Konzepts der unabhängigen Deploybarkeit ist – wir wollen also eine Änderung an unserem Service vornehmen und ihn in die Produktivumgebung deployen können, ohne etwas anderes ändern zu müssen. Damit das funktioniert, brauchen wir bei den von uns konsumierten Services Stabilität, und wir müssen einen stabilen Vertrag für die Services anbieten, die uns konsumieren.

Angesichts der vielen Informationen rund um diese Begriffe wäre es verrückt von mir, hier allzu umfangreich darauf einzugehen, aber ich denke, eine Zusammenfassung wäre trotzdem angebracht, insbesondere um diese Ideen in den Kontext von Microservices-Architekturen zu bringen. Schließlich beeinflussen diese Konzepte von Kohäsion und Kopplung sehr stark unser Denken über die Microservices-Architektur. Und das ist nicht überraschend – Kohäsion und Kopplung sind Aspekte modularer Software, und was ist Microservices-Architektur anderes als Module, die über Netzwerke kommunizieren und unabhängig deployt werden können?

Eine kurze Geschichte von Kopplung und Kohäsion

Die Konzepte von Kohäsion und Kopplung gibt es im Computerumfeld schon ziemlich lange. Ursprünglich wurden sie von Larry Constantine 1968 beschrieben. Diese Zwillingsideen von Kopplung und Kohärenz bildeten dann eine Grundlage dessen, wie wir über das Schreiben von Computerprogrammen denken. Bücher wie Structured Design von Larry Constantine und Edward Yourdon (Prentice Hall 1979) beeinflussten im Folgenden ganze Generationen von Programmierern (dieses Buch war Pflichtlektüre für mein Studium – nahezu 20 Jahre nach der Erstveröffentlichung).

Larry skizzierte seine Konzepte von Kohäsion und Kopplung erstmals 1968 (ein besonders vielversprechendes Jahr für die Informatik) auf dem National Symposium on Modular Programming – derselben Konferenz, auf der auch Conways Gesetz seinen Namen erhielt. Ebenfalls in diesem Jahr gab es zwei mittlerweile berüchtigte von der NATO geförderte Konferenzen, bei denen das Konzept des Software Engineering Bekanntheit erlangte (ein Begriff, der zuvor von Margaret H. Hamilton geprägt wurde).