Software-Architektur: Die schwierigen Teile

Kapitel 1. Was passiert, wenn eskeine "bewährten Methoden" gibt?

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Warum hält ein Technologe wie ein Softwarearchitekt einen Vortrag auf einer Konferenz oder schreibt ein Buch? Weil sie etwas entdeckt haben, was umgangssprachlich als "bewährte Methode" bezeichnet wird - ein Begriff, der so überstrapaziert wird, dass diejenigen, die ihn verwenden, zunehmend auf Ablehnung stoßen. Unabhängig von der Bezeichnung schreiben Technologen Bücher, wenn sie eine neuartige Lösung für ein allgemeines Problem gefunden haben und diese einem größeren Publikum zugänglich machen wollen.

Aber was passiert mit der riesigen Menge von Problemen, für die es keine guten Lösungen gibt? In der Softwarearchitektur gibt es ganze Klassen von Problemen, für die es keine allgemein guten Lösungen gibt, sondern nur eine unübersichtliche Reihe von Kompromissen, die einer (fast) ebenso unübersichtlichen Reihe gegenüberstehen.

Softwareentwickler/innen verfügen über hervorragende Fähigkeiten bei der Online-Suche nach Lösungen für ein aktuelles Problem. Wenn sie zum Beispiel herausfinden müssen, wie sie ein bestimmtes Tool in ihrer Umgebung konfigurieren können, finden sie mit Hilfe von Google die Antwort.

Aber das gilt nicht für Architekten.

Für Architekten stellen viele Probleme eine einzigartige Herausforderung dar, weil sie genau die Umgebung und die Umstände deines Unternehmens betreffen - wie groß ist die Wahrscheinlichkeit, dass jemand genau dieses Szenario schon einmal erlebt und in einem Blog oder auf Stack Overflow gepostet hat?

Architekten haben sich vielleicht schon gefragt, warum es so wenige Bücher über Architektur gibt, verglichen mit technischen Themen wie Frameworks, APIs und so weiter. Architekten haben selten mit alltäglichen Problemen zu kämpfen, sondern müssen ständig Entscheidungen in neuen Situationen treffen. Für Architekten ist jedes Problem eine Schneeflocke. In vielen Fällen ist das Problem nicht nur innerhalb einer bestimmten Organisation neu, sondern auf der ganzen Welt. Für diese Probleme gibt es keine Bücher oder Konferenzen!

Architektinnen und Architekten sollten nicht ständig nach Patentlösungen für ihre Probleme suchen. Sie sind heute so selten wie 1986, als Fred Brooks den Begriff prägte:

Es gibt keine einzige Entwicklung, weder in der Technologie noch in der Managementtechnik, die für sich genommen auch nur eine Größenordnung [das Zehnfache] an Produktivität, Zuverlässigkeit und Einfachheit innerhalb eines Jahrzehnts verspricht.

Fred Brooks aus "No Silver Bullet"

Da praktisch jedes Problem neue Herausforderungen mit sich bringt, liegt die eigentliche Aufgabe eines Architekten in seiner Fähigkeit, die Kompromisse auf beiden Seiten einer Entscheidung objektiv zu bestimmen und zu bewerten, um sie so gut wie möglich zu lösen. Die Autoren sprechen nicht von "besten Lösungen" (weder in diesem Buch noch in der realen Welt), denn "beste" bedeutet, dass ein Architekt es geschafft hat, alle möglichen konkurrierenden Faktoren innerhalb des Entwurfs zu maximieren. Stattdessen lautet unser augenzwinkernder Ratschlag wie folgt:

Tipp

Versuche nicht, das beste Design in der Softwarearchitektur zu finden; strebe stattdessen nach der am wenigsten schlechten Kombination von Kompromissen.

Oft ist der beste Entwurf, den ein Architekt erstellen kann, die am wenigsten schlechte Ansammlung von Kompromissen - kein einzelnes Architekturmerkmal ist so gut wie es allein wäre, aber die Ausgewogenheit aller konkurrierenden Architekturmerkmale fördert den Projekterfolg.

Das wirft die Frage auf: "Wie kann ein Architekt die am wenigsten schlechte Kombination von Kompromissen finden (und sie effektiv dokumentieren)?" In diesem Buch geht es in erster Linie um Entscheidungsfindung, damit Architekten bessere Entscheidungen treffen können, wenn sie mit neuenSituationen konfrontiert werden.

Warum "The Hard Parts"?

Warum haben wir dieses Buch Softwarearchitektur genannt ? The Hard Parts? Das "Hard" im Titel erfüllt eigentlich eine doppelte Aufgabe. Erstens bedeutet "hart" schwierig, und Architekten stehen ständig vor schwierigen Problemen, vor denen buchstäblich (und im übertragenen Sinne) noch niemand gestanden hat. Dabei geht es um zahlreiche technologische Entscheidungen mit langfristigen Auswirkungen, die über das zwischenmenschliche und politische Umfeld, in dem die Entscheidung getroffen werden muss, gelegt werden.

Zweitens steht " hart" für Solidität - genauwie bei der Trennung von Hard- und Software sollte sich das Harte viel weniger ändern, weil es die Grundlage für das Weiche bildet. In ähnlicher Weise diskutieren Architekten über die Unterscheidung zwischen Architektur und Design, wobei Ersteres strukturell ist und Letzteres leichter zu ändern ist. Daher sprechen wir in diesem Buch über die grundlegenden Teile der Architektur.

Die Definition von Softwarearchitektur selbst hat schon für viele Stunden unproduktiver Gespräche unter den Praktikern gesorgt. Eine beliebte, augenzwinkernde Definition lautet: "Softwarearchitektur ist das, was man später nur schwer ändern kann." Um diese Dinge geht es in unserem Buch.

Zeitlose Ratschläge zur Software-Architektur geben

Das Ökosystem der Softwareentwicklung verändert sich ständig und wächst chaotisch. Themen, die vor ein paar Jahren noch in aller Munde waren, wurden entweder vom Ökosystem aufgefangen und sind verschwunden oder wurden durch etwas anderes/besseres ersetzt. Vor 10 Jahren zum Beispiel war der vorherrschende Architekturstil für große Unternehmen die orchestrierte, serviceorientierte Architektur. Heute baut so gut wie niemand mehr in diesem Architekturstil (aus Gründen, die wir im Laufe der Zeit aufdecken werden); der aktuelle bevorzugte Stil für viele verteilte Systeme sind Microservices. Wie und warum kam es zu diesem Übergang?

Wenn Architekten einen bestimmten Stil betrachten (vor allem einen historischen), müssen sie die Zwänge berücksichtigen, die dazu geführt haben, dass sich diese Architektur durchgesetzt hat. Damals fusionierten viele Unternehmen zu Großkonzernen, mit all den damit verbundenen Integrationsproblemen. Außerdem war Open Source für große Unternehmen keine realisierbare Option (oft aus politischen und nicht aus technischen Gründen). Daher setzten die Architekten auf gemeinsame Ressourcen und eine zentralisierte Orchestrierung alsLösung.

In den dazwischen liegenden Jahren wurden Open Source und Linux jedoch zu brauchbaren Alternativen, die Betriebssysteme kommerziell kostenlos machten. Der eigentliche Wendepunkt kam jedoch, als Linux mit dem Aufkommen von Tools wie Puppet und Chef, die es Entwicklungsteams ermöglichten, ihre Umgebungen als Teil eines automatisierten Builds zu programmieren, für den Betrieb freigegeben wurde. Mit dieser Fähigkeit wurde eine architektonische Revolution mit Microservices und der schnell entstehenden Infrastruktur von Containern und Orchestrierungswerkzeugen wie Kubernetes eingeleitet.

Dies zeigt, dass sich das Ökosystem der Softwareentwicklung auf völlig unerwartete Weise erweitert und weiterentwickelt. Eine neue Fähigkeit führt zu einer anderen, die unerwartet neue Fähigkeiten schafft. Im Laufe der Zeit ersetzt sich das Ökosystem selbst, ein Stück nach dem anderen.

Dies stellt ein uraltes Problem für Autoren von Büchern über Technologie im Allgemeinen und Softwarearchitektur im Besonderen dar - wie können wir etwas schreiben, das nicht sofort veraltet ist?

Wir konzentrieren uns in diesem Buch nicht auf die Technologie oder andere Implementierungsdetails. Vielmehr konzentrieren wir uns darauf, wie Architekten Entscheidungen treffen und wie sie Kompromisse objektiv abwägen können, wenn sie mit neuen Situationen konfrontiert werden. Wir verwenden aktuelle Szenarien und Beispiele, um Details und Kontext zu vermitteln, aber die zugrundeliegenden Prinzipien konzentrieren sich auf die Analyse von Kompromissen und die Entscheidungsfindung, wenn wir mit neuen Problemen konfrontiert werden.

Die Bedeutung von Daten in der Architektur

Daten sind ein kostbares Gut und werden länger halten als die Systeme selbst.

Tim Berners-Lee

Für viele in der Architektur sind Daten alles. Jedes Unternehmen muss sich beim Aufbau eines Systems mit Daten befassen, da diese in der Regel viel länger leben als Systeme oder Architekturen und daher sorgfältige Überlegungen und Entwürfe erfordern. Viele der Instinkte von Datenarchitekten, eng gekoppelte Systeme zu bauen, führen jedoch zu Konflikten in modernen verteilten Architekturen. So müssen Architekten und DBAs zum Beispiel sicherstellen, dass die Geschäftsdaten das Auseinanderbrechen monolithischer Systeme überleben und dass das Unternehmen unabhängig von Architekturschwankungen weiterhin einen Nutzen aus seinen Daten ziehen kann.

Es wird gesagt, dass Daten das wichtigste Kapital eines Unternehmens sind. Unternehmen wollen den Wert ihrer Daten ausschöpfen und finden neue Wege, um Daten für die Entscheidungsfindung zu nutzen. Jeder Teil des Unternehmens ist heute datengesteuert, von der Betreuung bestehender Kunden über die Gewinnung neuer Kunden, die Erhöhung der Kundenbindung, die Verbesserung von Produkten, die Vorhersage von Umsätzen und andere Trends. Diese Abhängigkeit von Daten bedeutet, dass die gesamte Softwarearchitektur im Dienste der Daten steht und sicherstellt, dass die richtigen Daten verfügbar sind und von allen Teilen des Unternehmens genutzt werden können.

Die Autoren haben vor einigen Jahrzehnten viele verteilte Systeme gebaut, als diese populär wurden, doch die Entscheidungsfindung in modernen Microservices scheint schwieriger zu sein, und wir wollten herausfinden, warum. Wir wollten herausfinden, warum. Schließlich wurde uns klar, dass wir in den Anfängen der verteilten Architektur die Daten meist noch in einer einzigen relationalen Datenbank gespeichert haben. Mit Microservices und dem philosophischen Ansatz des Domain-Driven Design, den Umfang der Detailkopplung bei der Implementierung zu begrenzen, sind Daten jedoch zu einem architektonischen Anliegen geworden, ebenso wie die Transaktionsfähigkeit. Viele der Schwierigkeiten der modernen Architektur ergeben sich aus den Spannungen zwischen Daten- und Architekturbelangen, die wir in Teil I und Teil II auflösen.

Eine wichtige Unterscheidung, die wir in verschiedenen Kapiteln behandeln, ist die Trennung zwischen operativen und analytischen Daten:

Operative Daten

Daten, die für den Betrieb des Unternehmens verwendet werden, einschließlich Verkäufe, Transaktionsdaten, Inventar und so weiter. Diese Daten sind die Grundlage des Unternehmens - wenn etwas diese Daten unterbricht, kann das Unternehmen nicht lange funktionieren. Diese Art von Daten wird als Online Transactional Processing (OLTP) bezeichnet, was in der Regel das Einfügen, Aktualisieren und Löschen von Daten in einer Datenbank beinhaltet.

Analytische Daten

Daten, die von Data Scientists und anderen Unternehmensanalysten für Vorhersagen, Trendanalysen und andere Business Intelligence genutzt werden. Diese Daten sind in der Regel nicht transaktional und oft auch nicht relational - sie können in einer Graphdatenbank oder in Snapshots in einem anderen Format als der ursprünglichen transaktionalen Form vorliegen. Diese Daten sind nicht entscheidend für den täglichen Betrieb, sondern eher für die langfristige strategische Ausrichtung und Entscheidungen.

Wir behandeln die Auswirkungen von operativen und analytischen Daten in diesem Buch.

Aufzeichnungen über architektonische Entscheidungen

Eine der effektivsten Methoden zur Dokumentation von Architekturentscheidungen sind die Architectural Decision Records(ADRs). ADRs wurden zuerst von Michael Nygard in einem Blogbeitrag propagiert und später im Thoughtworks Technology Radar als "adopt" markiert. Ein ADR besteht aus einer kurzen Textdatei (normalerweise ein bis zwei Seiten lang), die eine bestimmte Architekturentscheidung beschreibt. ADRs können zwar auch als reiner Text verfasst werden, aber normalerweise werden sie in einem Textdokumentenformat wie AsciiDoc oder Markdown geschrieben. Alternativ kann ein ADR auch mit einer Wikiseitenvorlage geschrieben werden. In unserem letzten Buch, Fundamentals of Software Architecture (O'Reilly), haben wir den ADRs ein ganzes Kapitel gewidmet.

Wir werden ADRs nutzen, um verschiedene Architekturentscheidungen zu dokumentieren, die im Laufe des Buches getroffen werden. Für jede Architekturentscheidung werden wir das folgende ADR-Format verwenden, wobei wir davon ausgehen, dass jedes ADR genehmigt wird:

ADR: Eine kurze Substantivphrase, die die Architekturentscheidung enthält

Kontext
In diesem Abschnitt des ADR fügen wir eine kurze ein- oder zweisätzige Beschreibung des Problems hinzu und listen die alternativen Lösungen auf.

Entscheidung
In diesem Abschnitt geben wir die Entscheidung für die Architektur an und begründen sie ausführlich.

Konsequenzen
In diesem Abschnitt des ADR beschreiben wir alle Konsequenzen, die sich aus der Anwendung der Entscheidung ergeben, und gehen auf die Kompromisse ein, die in Betracht gezogen wurden.

Eine Liste aller architektonischen Entscheidungsprotokolle, die in diesem Buch erstellt wurden, findest du in Anhang B.

Eine Entscheidung zu dokumentieren ist für einen Architekten wichtig, aber die ordnungsgemäße Verwendung der Entscheidung zu regeln, ist ein anderes Thema. Glücklicherweise lassen sich mit modernen Konstruktionsverfahren viele gängige Governance-Belange mithilfe vonArchitektur-Fitnessfunktionen automatisieren.

Architektur Fitnessfunktionen

Wenn ein Architekt die Beziehungen zwischen den Komponenten identifiziert und in einem Entwurf kodifiziert hat, wie kann er dann sicherstellen, dass sich die Umsetzer an diesen Entwurf halten? Ganz allgemein gefragt: Wie können Architekten sicherstellen, dass die von ihnen definierten Entwurfsprinzipien Wirklichkeit werden, wenn sie nicht diejenigen sind, die sie umsetzen?

Diese Fragen fallen unter den Begriff der Architektur-Governance, der sich auf jede organisierte Aufsicht über einen oder mehrere Aspekte der Softwareentwicklung bezieht. Da es in diesem Buch vor allem um die Architekturstruktur geht, behandeln wir an vielen Stellen, wie man Design- und Qualitätsprinzipien über Fitnessfunktionen automatisieren kann.

Die Softwareentwicklung hat sich im Laufe der Zeit langsam weiterentwickelt und einzigartige technische Praktiken angepasst. In den Anfängen der Softwareentwicklung wurde häufig eine Fertigungsmetapher auf Softwarepraktiken angewandt, und zwar sowohl im Großen (wie der Wasserfall-Entwicklungsprozess) als auch im Kleinen (Integrationspraktiken in Projekten). In den frühen 1990er Jahren wurde unter der Leitung von Kent Beck und den anderen Ingenieuren des C3-Projekts die Softwareentwicklung unter dem Namen eXtreme Programming (XP) neu überdacht und die Bedeutung von inkrementellem Feedback und Automatisierung als Schlüsselfaktoren für die Produktivität der Softwareentwicklung herausgestellt. In den frühen 2000er Jahren wurden dieselben Lehren auf die Schnittstelle zwischen Softwareentwicklung und Betrieb angewandt, wodurch die neue Rolle von DevOps entstand und viele ehemals manuelle Betriebsaufgaben automatisiert wurden. Die Automatisierung ermöglicht es den Teams nach wie vor, schneller zu arbeiten, weil sie sich keine Sorgen machen müssen, dass etwas ohne gutes Feedback nicht funktioniert. So sind Automatisierung und Feedback zu zentralen Grundsätzen für eine effektive Softwareentwicklung geworden.

Betrachte die Umgebungen und Situationen, die zu Durchbrüchen in der Automatisierung führen. In der Ära vor der kontinuierlichen Integration beinhalteten die meisten Softwareprojekte eine langwierige Integrationsphase. Von jedem Entwickler wurde erwartet, dass er in einer gewissen Isolation von den anderen arbeitet und den gesamten Code am Ende in eine Integrationsphase integriert. Die Spuren dieser Praxis finden sich noch immer in Versionskontroll-Tools, die Verzweigungen erzwingen und eine kontinuierliche Integration verhindern. Es überrascht nicht, dass es eine starke Korrelation zwischen der Projektgröße und dem Aufwand für die Integrationsphase gibt. Als Pionier der kontinuierlichen Integration hat das XP-Team gezeigt, wie wichtig schnelles, kontinuierliches Feedback ist.

Die DevOps-Revolution hat einen ähnlichen Verlauf genommen. Als Linux und andere Open-Source-Software für Unternehmen "gut genug" wurden und gleichzeitig Tools aufkamen, die eine programmatische Definition von (schließlich) virtuellen Maschinen ermöglichten, erkannten die Betriebsmitarbeiter, dass sie Maschinendefinitionen und viele andere sich wiederholende Aufgaben automatisieren konnten.

In beiden Fällen haben technologische Fortschritte und neue Erkenntnisse dazu geführt, dass eine wiederkehrende Aufgabe automatisiert werden konnte, die bisher von einer teuren Rolle erledigt wurde - was den aktuellen Zustand der Architektur-Governance in den meisten Unternehmen beschreibt. Wenn ein Architekt zum Beispiel einen bestimmten Architekturstil oder ein bestimmtes Kommunikationsmedium auswählt, wie kann er dann sicherstellen, dass ein Entwickler es richtig umsetzt? Wenn dies manuell geschieht, führen Architekten Codeüberprüfungen durch oder halten vielleicht Architekturprüfungsgremien ab, um den Stand der Governance zu beurteilen. Doch genau wie bei der manuellen Konfiguration von Computern im Betrieb können wichtige Details leicht durch oberflächliche Überprüfungen fallen.

Fitnessfunktionen verwenden

In dem 2017 erschienenen Buch Building Evolutionary Architectures (O'Reilly) haben die Autoren (Neal Ford, Rebecca Parsons und Patrick Kua) das Konzept einer architektonischen Fitnessfunktion definiert: jeder Mechanismus, der eine objektive Integritätsbewertung eines Architekturmerkmals oder einer Kombination von Architekturmerkmalen vornimmt. Hier ist eine Punkt-für-Punkt-Aufschlüsselung dieser Definition:

Jeder Mechanismus

Architekten können eine Vielzahl von Tools verwenden, um Fitnessfunktionen zu implementieren; wir werden im Laufe des Buches zahlreiche Beispiele zeigen. So gibt es z. B. spezielle Testbibliotheken, um die Struktur der Architektur zu testen, Architekten können Monitore verwenden, um operative Architektureigenschaften wie Leistung oder Skalierbarkeit zu prüfen, und Chaos-Engineering-Frameworks testen Zuverlässigkeit und Ausfallsicherheit.

Objektive Integritätsbewertung

Eine wichtige Voraussetzung für eine automatisierte Steuerung sind objektive Definitionen für Architekturmerkmale. Ein Architekt kann zum Beispiel nicht angeben, dass er eine "leistungsstarke" Website haben möchte, sondern muss einen Objektwert angeben, der durch einen Test, einen Monitor oder eine andere Fitnessfunktion gemessen werden kann.

Architekten müssen sich vor zusammengesetzten Architekturmerkmalen hüten - solche die nicht objektiv messbar sind, sondern in Wirklichkeit Zusammensetzungen anderer messbarer Dinge sind. Zum Beispiel ist "Agilität" nicht messbar, aber wenn ein Architekt den weit gefassten Begriff " Agilität" auseinander nimmt, geht es darum, dass Teams schnell und sicher auf Veränderungen reagieren können, sei es im Ökosystem oder im Bereich. So kann ein Architekt messbare Merkmale finden, die zur Agilität beitragen: Einsatzfähigkeit, Testbarkeit, Zykluszeit und so weiter. Wenn sich eine Architektureigenschaft nicht messen lässt, bedeutet das oft, dass die Definition zu vage ist. Wenn Architekten messbare Eigenschaften anstreben, können sie die Anwendung von Fitnessfunktionen automatisieren.

Ein Architekturmerkmal oder eine Kombination von Architekturmerkmalen

Dieses Merkmal beschreibt die beiden Geltungsbereiche für Fitnessfunktionen:

Atomic

Diese Fitnessfunktionen behandeln ein einzelnes Architekturmerkmal in Isolation. Eine Fitnessfunktion, die auf Komponentenzyklen innerhalb einer Codebasis prüft, ist zum Beispiel atomar ausgerichtet.

Ganzheitlich

Ganzheitliche Fitnessfunktionen überprüfen eine Kombination von Architekturmerkmalen. Ein kompliziertes Merkmal von Architekturmerkmalen sind die Synergien, die sie manchmal mit anderen Architekturmerkmalen aufweisen. Wenn ein Architekt zum Beispiel die Sicherheit verbessern will, ist die Wahrscheinlichkeit groß, dass dies die Leistung beeinträchtigt. Auch Skalierbarkeit und Elastizität stehen manchmal im Widerspruch zueinander - die Unterstützung einer großen Anzahl von gleichzeitigen Nutzern kann die Bewältigung plötzlicher Ausbrüche erschweren. Ganzheitliche Fitnessfunktionen prüfen eine Kombination von ineinandergreifenden Architekturmerkmalen, um sicherzustellen, dass die kombinierte Wirkung sich nicht negativ auf die Architektur auswirkt.

Ein Architekt implementiert Fitnessfunktionen, um Schutzmaßnahmen gegen unerwartete Änderungen der Architekturmerkmale zu entwickeln. In der Welt der agilen Softwareentwicklung führen Entwickler Unit-, Funktions- und Benutzerakzeptanztests durch, um die verschiedenen Dimensionen des Domänenentwurfs zu überprüfen. Bisher gab es jedoch keinen ähnlichen Mechanismus, um die Architekturmerkmale des Entwurfs zu überprüfen. Die Trennung zwischen Fitness-Funktionen und Unit-Tests ist ein guter Leitfaden für Architekten. Fitnessfunktionen validieren Architekturmerkmale, nicht Domänenkriterien; Unit-Tests sind das Gegenteil davon. Ein Architekt kann also entscheiden, ob eine Fitnessfunktion oder ein Unit-Test benötigt wird, indem er sich die Frage stellt: "Ist für die Durchführung dieses Tests Fachwissen erforderlich?" Wenn die Antwort "Ja" lautet, ist ein Unit-/Funktions-/Benutzerakzeptanztest angemessen; wenn "Nein", ist eine Fitnessfunktion erforderlich.

Wenn Architekten zum Beispiel von Elastizität sprechen, ist damit die Fähigkeit der Anwendung gemeint, einem plötzlichen Ansturm von Nutzern standzuhalten. Beachte, dass der Architekt keine Details über den Bereich wissen muss - das kann eine E-Commerce-Seite, ein Online-Spiel oder etwas anderes sein. Die Elastizität ist also ein architektonisches Anliegen und liegt im Rahmen einer Fitnessfunktion. Wenn der Architekt hingegen die korrekten Teile einer Postadresse überprüfen möchte, wird dies durch einen traditionellen Test abgedeckt. Natürlich ist diese Trennung nicht rein binär - manche Fitnessfunktionen berühren die Domäne und umgekehrt, aber die unterschiedlichen Ziele bieten eine gute Möglichkeit, sie gedanklich zu trennen.

Hier sind ein paar Beispiele, um das Konzept weniger abstrakt zu machen.

Ein gemeinsames Ziel von Architekten ist es, eine gute interne strukturelle Integrität der Codebasis zu erhalten. Auf vielen Plattformen arbeiten jedoch böswillige Kräfte gegen die guten Absichten des Architekten. Sobald ein Entwickler in einer gängigen Java- oder .NET-Entwicklungsumgebung eine Klasse referenziert, die noch nicht importiert wurde, zeigt die IDE einen Dialog an, in dem der Entwickler gefragt wird, ob er die Referenz automatisch importieren möchte. Das passiert so oft, dass die meisten Programmierer/innen sich angewöhnt haben, den Auto-Import-Dialog reflexartig wegzuwischen.

Das willkürliche Importieren von Klassen oder Komponenten untereinander ist jedoch eine Katastrophe für die Modularität. Abbildung 1-1 zeigt zum Beispiel ein besonders schädliches Muster, das Architekten vermeiden sollten.

Abbildung 1-1. Zyklische Abhängigkeiten zwischen Komponenten

Bei diesem Anti-Muster verweist jede Komponente auf etwas in den anderen. Ein solches Netzwerk von Komponenten schadet der Modularität, weil ein Entwickler eine einzelne Komponente nicht wiederverwenden kann, ohne die anderen mit einzubeziehen. Und wenn die anderen Komponenten an andere Komponenten gekoppelt sind, neigt die Architektur immer mehr zum Big Ball of Mud-Anti-Muster. Wie können Architekten dieses Verhalten steuern, ohne den schießwütigen Entwicklern ständig über die Schulter zu schauen? Codeüberprüfungen helfen, aber sie finden zu spät im Entwicklungszyklus statt, um effektiv zu sein. Wenn ein Architekt zulässt, dass ein Entwicklungsteam bis zur Codeüberprüfung eine Woche lang hemmungslos in die Codebasis einführt, ist bereits ein großer Schaden in der Codebasis entstanden.

Die Lösung für dieses Problem ist, eine Fitnessfunktion zu schreiben, um Komponentenzyklen zu vermeiden, wie in Beispiel 1-1 gezeigt.

Beispiel 1-1. Fitnessfunktion zur Erkennung von Komponentenzyklen

public class CycleTest {
    private JDepend jdepend;

    @BeforeEach
    void init() {
	  jdepend = new JDepend();
	  jdepend.addDirectory("/path/to/project/persistence/classes");
	  jdepend.addDirectory("/path/to/project/web/classes");
	  jdepend.addDirectory("/path/to/project/thirdpartyjars");
    }

    @Test
    void testAllPackages() {
	  Collection packages = jdepend.analyze();
	  assertEquals("Cycles exist", false, jdepend.containsCycles());
    }
}

Im Code verwendet ein Architekt das Metrik-Tool JDepend, um die Abhängigkeiten zwischen Paketen zu prüfen. Das Tool versteht die Struktur von Java-Paketen und schlägt den Test fehl, wenn es irgendwelche Zyklen gibt. Ein Architekt kann diesen Test in den kontinuierlichen Build eines Projekts einbinden und muss sich keine Sorgen mehr über die versehentliche Einführung von Zyklen durch schießwütige Entwickler machen. Dies ist ein großartiges Beispiel für eine Fitnessfunktion, die eher die wichtigen als die dringenden Praktiken der Softwareentwicklungschützt: Sie ist ein wichtiges Anliegen für Architekten, hat aber kaum Auswirkungen auf die tägliche Programmierung.

Beispiel 1-1 zeigt eine sehr einfache, codezentrierte Fitnessfunktion. Viele gängige Code-Hygiene-Tools (wie SonarQube) implementieren viele gängige Fitness-Funktionen schlüsselfertig. Architekten möchten jedoch möglicherweise nicht nur die Mikro-, sondern auch die Makrostruktur der Architektur überprüfen. Beim Entwurf einer Schichtenarchitektur wie in Abbildung 1-2 definiert der Architekt die Schichten, um die Trennung von Belangen sicherzustellen.

Abbildung 1-2. Traditionelle mehrschichtige Architektur

Aber wie kann der Architekt sicherstellen, dass die Entwickler diese Schichten respektieren? Einige Entwickler verstehen vielleicht nicht, wie wichtig die Muster sind, während andere aus übergeordneten lokalen Gründen, wie z. B. der Leistung, lieber um Vergebung als um Erlaubnis bitten. Aber wenn man den Entwicklern erlaubt, die Gründe für die Architektur zu untergraben, schadet das der langfristigen Gesundheit der Architektur.

ArchUnit ermöglicht es Architekten, dieses Problem mithilfe einer Fitnessfunktion zu lösen, wie in Beispiel 1-2 gezeigt.

Beispiel 1-2. ArchUnit Fitnessfunktion zur Steuerung von Schichten

layeredArchitecture()
    .layer("Controller").definedBy("..controller..")
    .layer("Service").definedBy("..service..")
    .layer("Persistence").definedBy("..persistence..")

    .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
    .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
    .whereLayer("Persistence").mayOnlyBeAccessedByLayers("Service")

In Beispiel 1-2 definiert der Architekt die wünschenswerte Beziehung zwischen den Schichten und schreibt eine Verifizierungsfunktion, um sie zu steuern. Auf diese Weise kann der Architekt Architekturprinzipien außerhalb von Diagrammen und anderen informativen Artefakten festlegen und sie laufend verifizieren.

Ein ähnliches Tool im .NET-Bereich, NetArchTest, ermöglicht ähnliche Tests für diese Plattform. Eine Ebenenprüfung in C# wird in Beispiel 1-3 gezeigt.

Beispiel 1-3. NetArchTest für Layer-Abhängigkeiten

// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("NetArchTest.SampleLibrary.Presentation")
    .ShouldNot()
    .HaveDependencyOn("NetArchTest.SampleLibrary.Data")
    .GetResult()
    .IsSuccessful;

In diesem Bereich gibt es immer mehr und immer ausgefeiltere Tools. Wir werden weiterhin viele dieser Techniken hervorheben, indem wir Fitnessfunktionen zusammen mit vielen unserer Lösungen illustrieren.

Es ist wichtig, ein objektives Ergebnis für eine Fitnessfunktion zu finden. Allerdings bedeutet objektiv nicht gleich statisch. Einige Fitnessfunktionen haben kontextunabhängige Rückgabewerte, z. B. wahr/falsch oder einen numerischen Wert wie einen Leistungsschwellenwert. Andere Fitnessfunktionen (die als dynamisch bezeichnet werden) geben jedoch einen Wert zurück, der auf einem bestimmten Kontext basiert. Bei der Messung der Skalierbarkeit messen Architekten zum Beispiel die Anzahl der gleichzeitigen Nutzer und in der Regel auch die Leistung für jeden Nutzer. Oft entwerfen Architekten ihre Systeme so, dass die Leistung pro Benutzer mit steigender Benutzerzahl leicht abnimmt, aber nicht über eine Klippe stürzt. Für diese Systeme entwickeln die Architekten daher Leistungsfitnessfunktionen, die die Anzahl der gleichzeitigen Nutzer berücksichtigen. Solange das Maß für eine Architektureigenschaft objektiv ist, können Architekten sie testen.

Während die meisten Fitnessfunktionen automatisiert und kontinuierlich ausgeführt werden sollten, werden einige zwangsläufig manuell ausgeführt. Eine manuelle Fitnessfunktion erfordert eine Person, die die Validierung vornimmt. Bei Systemen mit sensiblen rechtlichen Informationen muss zum Beispiel ein Anwalt die Änderungen an kritischen Teilen überprüfen, um die Rechtmäßigkeit sicherzustellen, was nicht automatisiert werden kann. Die meisten Deployment-Pipelines unterstützen manuelle Phasen, so dass die Teams manuelle Fitnessfunktionen einbauen können. Im Idealfall werden diese so oft wie möglich ausgeführt - eine nicht durchgeführte Validierung kann nichts validieren. Teams führen Fitnessfunktionen entweder bei Bedarf (selten) oder als Teil eines kontinuierlichen Integrations-Workflows (amhäufigsten) aus. Um den Nutzen von Validierungen wie Fitnessfunktionen voll auszuschöpfen, sollten sie kontinuierlich ausgeführt werden.

Kontinuität ist wichtig, wie dieses Beispiel für eine unternehmensweite Governance mit Fitnessfunktionen zeigt. Stell dir folgendes Szenario vor: Was macht ein Unternehmen, wenn ein Zero-Day-Exploit in einem der Entwicklungs-Frameworks oder Bibliotheken entdeckt wird, die das Unternehmen verwendet? Wie in den meisten Unternehmen durchforsten Sicherheitsexperten die Projekte, um die angreifende Version des Frameworks zu finden und sicherzustellen, dass sie aktualisiert wird. Das ist keine abstrakte Frage; genau dieses Szenario betraf ein großes Finanzinstitut, das im Bericht The Equifax Data Breach beschrieben wird. Wie bei der zuvor beschriebenen Architektur-Governance sind auch hier manuelle Prozesse fehleranfällig und erlauben es, Details zu übersehen.

Der Equifax-Datenmissbrauch

Am 7. September 2017 gab Equifax, eine große Kreditauskunftei in den USA, bekannt, dass es zu einer Datenpanne gekommen war. Letztlich wurde das Problem auf einen Hacking-Exploit des beliebten Struts-Webframeworks im Java-Ökosystem zurückgeführt (Apache Struts vCVE-2017-5638). Die Stiftung gab eine Erklärung über die Sicherheitslücke ab und veröffentlichte am 7. März 2017 einen Patch. Das Heimatschutzministerium setzte sich am nächsten Tag mit Equifax und ähnlichen Unternehmen in Verbindung und warnte sie vor diesem Problem, woraufhin sie am 15. März 2017 Scans durchführten, die jedoch nicht alle betroffenen Systeme aufzeigten. Daher wurde der kritische Patch erst am 29. Juli 2017 auf viele ältere Systeme aufgespielt, als die Sicherheitsexperten von Equifax das Hacking-Verhalten feststellten, das zu dem Datenverstoß führte.

Stell dir eine alternative Welt vor, in der jedes Projekt eine Deployment-Pipeline durchläuft und das Sicherheitsteam einen "Slot" in der Deployment-Pipeline jedes Teams hat, in dem es Fitness-Funktionen einsetzen kann. Meistens handelt es sich dabei um banale Überprüfungen von Sicherheitsvorkehrungen, z. B. um zu verhindern, dass Entwickler Passwörter in Datenbanken speichern, und um ähnliche reguläre Verwaltungsaufgaben. Wenn jedoch ein Zero-Day-Exploit auftaucht, kann das Sicherheitsteam mit dem gleichen Mechanismus in jedem Projekt einen Test einfügen, der auf ein bestimmtes Framework und eine bestimmte Versionsnummer prüft; wenn er die gefährliche Version findet, schlägt der Build fehl und das Sicherheitsteam wird benachrichtigt. Die Teams konfigurieren die Deployment-Pipelines so, dass sie bei jeder Änderung des Ökosystems aktiviert werden: Code, Datenbankschema, Deployment-Konfiguration und Fitnessfunktionen. So können Unternehmen wichtige Governance-Aufgaben durchgängig automatisieren.

Fitnessfunktionen bieten viele Vorteile für Architekten, nicht zuletzt die Möglichkeit, wieder etwas zu programmieren! Eine der häufigsten Klagen unter Architekten ist, dass sie nicht mehr viel programmieren - aber Fitnessfunktionen sind oft Code! Durch die Erstellung einer ausführbaren Spezifikation der Architektur, die jeder jederzeit überprüfen kann, indem er den Build des Projekts ausführt, müssen Architekten das System und seine laufende Entwicklung gut verstehen, was sich mit dem Kernziel überschneidet, mit dem Code des Projekts Schritt zu halten, während es wächst.

So mächtig Fitnessfunktionen auch sein mögen, Architekten sollten sie nicht übermäßig einsetzen. Architekten sollten keine Kabale bilden und sich in einen Elfenbeinturm zurückziehen, um einen unmöglich komplexen, ineinandergreifenden Satz von Fitnessfunktionen zu erstellen, der Entwickler und Teams nur frustriert. Stattdessen können Architekten eine ausführbare Checkliste mit wichtigen, aber nicht dringenden Prinzipien für Softwareprojekte erstellen. Viele Projekte ertrinken in der Dringlichkeit und lassen dabei einige wichtige Prinzipien unter den Tisch fallen. Das ist die häufige Ursache für technische Schulden: "Wir wissen, dass das schlecht ist, aber wir werden es später korrigieren" - und später kommt nie. Indem sie Regeln für die Codequalität, die Struktur und andere Sicherheitsvorkehrungen gegen den Verfall in Fitnessfunktionen kodieren, die ständig ausgeführt werden, erstellen Architekten eine Qualitäts-Checkliste, die die Entwickler nicht überspringen können.

Vor ein paar Jahren hat Atul Gawande in seinem hervorragenden Buch The Checklist Manifesto (Picador) die Verwendung von Checklisten durch Fachleute wie Chirurgen, Piloten und andere Berufsgruppen hervorgehoben, die Checklisten als Teil ihrer Arbeit verwenden (manchmal per Gesetz). Das liegt nicht daran, dass sie ihren Job nicht kennen oder besonders vergesslich sind; wenn Fachleute dieselbe Aufgabe immer wieder ausführen, wird es leicht, sich etwas vorzumachen, wenn es versehentlich übersprungen wird, und Checklisten verhindern das. Fitnessfunktionen sind eine Checkliste mit wichtigen Prinzipien, die von Architekten festgelegt und während der Erstellung ausgeführt werden, um sicherzustellen, dass die Entwickler sie nicht versehentlich (oder absichtlich, z. B. aufgrund von Termindruck) übergehen.

Wir verwenden Fitnessfunktionen im gesamten Buch, wenn sich die Gelegenheit bietet, die Steuerung einer architektonischen Lösung sowie den ursprünglichen Entwurf zu veranschaulichen.

Architektur vs. Design: Definitionen einfach halten

Ein ständiger Kampf für Architekten ist es, Architektur und Design als getrennte, aber verwandte Tätigkeiten zu betrachten. Auch wenn wir uns nicht in den endlosen Streit um diese Unterscheidung einmischen wollen, bemühen wir uns in diesem Buch aus mehreren Gründen, fest auf der Architekturseite des Spektrums zu bleiben.

Zunächst müssen Architekten die zugrunde liegenden Architekturprinzipien verstehen, um effektive Entscheidungen treffen zu können. Zum Beispiel gibt es bei der Entscheidung zwischen synchroner und asynchroner Kommunikation eine Reihe von Kompromissen, bevor die Architekten die Details der Implementierung festlegen. In dem Buch Fundamentals of Software Architecture haben die Autoren das zweite Gesetz der Softwarearchitektur formuliert: Das Warum ist wichtiger als das Wie. Architekten müssen zwar wissen, wie man Lösungen implementiert, aber sie müssen zuerst verstehen, warum eine Entscheidung bessere Kompromisse mit sich bringt als eine andere.

Zweitens können wir durch die Konzentration auf Architekturkonzepte die zahlreichen Implementierungen dieser Konzepte vermeiden. Architekten können asynchrone Kommunikation auf verschiedene Weise implementieren. Wir konzentrieren uns darauf, warum sich ein Architekt für asynchrone Kommunikation entscheidet und überlassen die Details der Implementierung einem anderen Ort.

Drittens: Wenn wir uns auf den Weg machen würden, alle von uns gezeigten Optionen zu implementieren, wäre dies das längste Buch, das je geschrieben wurde. Die Konzentration auf die Architekturprinzipien ermöglicht es uns, die Dinge so allgemein wie möglich zu halten.

Um die Themen so architekturbezogen wie möglich zu halten, verwenden wir möglichst einfache Definitionen für die wichtigsten Konzepte. Die Kopplung in der Architektur zum Beispiel könnte ganze Bücher füllen (und hat es auch getan). Zu diesem Zweck verwenden wir die folgenden einfachen, fast schon simplen Definitionen:

Service

Umgangssprachlich ist ein Service eine zusammenhängende Sammlung von Funktionen, die als unabhängige ausführbare Datei bereitgestellt werden. Die meisten Konzepte, die wir im Zusammenhang mit Diensten erörtern, gelten allgemein für verteilte Architekturen und insbesondere für Microservices-Architekturen.

In den Begriffen, die wir in Kapitel 2 definieren, ist ein Service Teil eines Architekturquantums, das weitere Definitionen sowohl der statischen als auch der dynamischen Kopplung zwischen Services und anderen Quanten enthält.

Kupplung

Zwei Artefakte (einschließlich Dienste) sind gekoppelt, wenn eine Änderung in einem Artefakt eine Änderung im anderen Artefakt erfordert, um die Funktionalität zu erhalten.

Komponente

Ein architektonischer Baustein der Anwendung, der eine Art von Geschäfts- oder Infrastrukturfunktion erfüllt, in der Regel durch eine Paketstruktur (Java), einen Namensraum (C#) oder eine physische Gruppierung von Quellcodedateien in einer Art Verzeichnisstruktur manifestiert. Die Komponente Auftragshistorie könnte zum Beispiel durch eine Reihe von Klassendateien implementiert werden, die sich im Namespace app.business.order.history befinden.

Synchrone Kommunikation

Zwei Artefakte kommunizieren synchron, wenn der Aufrufer auf die Antwort warten muss, bevor er fortfahren kann.

Asynchrone Kommunikation

Zwei Artefakte kommunizieren asynchron, wenn der Aufrufer nicht auf die Antwort von wartet, bevor er fortfährt. Optional kann der Aufrufer vom Empfänger über einen separaten Kanal benachrichtigt werden, wenn die Anfrage abgeschlossen ist.

Orchestrierte Koordination

Ein Workflow ist orchestriert, wenn er einen Dienst enthält, dessen Hauptaufgabe die Koordination des Workflows ist.

Choreografierte Koordination

Ein Workflow ist choreografiert, wenn er keinen Orchestrator hat; vielmehr teilen sich die Dienste im Workflow die Koordinationsaufgaben des Workflows.

Atomarität

Ein Arbeitsablauf ist atomar, wenn alle Teile des Arbeitsablaufs zu jeder Zeit einen konsistenten Zustand beibehalten; das Gegenteil ist das Spektrum der eventuellen Konsistenz, das in Kapitel 6 behandelt wird.

Vertrag

Wir verwenden den Begriff Vertrag im weitesten Sinne, um die Schnittstelle zwischen zwei Softwareteilen zu definieren, die Methoden- oder Funktionsaufrufe, Remote-Aufrufe der Integrationsarchitektur, Abhängigkeiten und so weiter umfassen kann. Überall dort, wo zwei Teile einer Software zusammenkommen, ist ein Vertrag involviert.

Softwarearchitektur ist von Natur aus abstrakt: Wir können nicht wissen, welche einzigartige Kombination von Plattformen, Technologien, kommerzieller Software und anderen schwindelerregenden Möglichkeiten unsere Leser haben, außer dass keine zwei genau gleich sind. Wir behandeln viele abstrakte Ideen, müssen sie aber mit einigen Implementierungsdetails untermauern, um sie konkret zu machen. Dazu brauchen wir ein Problem, mit dem wir die Architekturkonzepte veranschaulichen können - und das führt uns zur Sysops Squad.

Vorstellung der Sysops Squad Saga

saga

Eine lange Geschichte von Heldentaten.

Oxford English Dictionary

Wir besprechen in diesem Buch eine Reihe von Sagas, sowohl im wörtlichen als auch im übertragenen Sinne. Architekten haben den Begriff Saga übernommen, um das transaktionale Verhalten in verteilten Architekturen zu beschreiben (was wir in Kapitel 12 ausführlich behandeln). Diskussionen über Architekturen neigen jedoch dazu, abstrakt zu werden, besonders wenn es um abstrakte Probleme wie die harten Teile der Architektur geht. Um dieses Problem zu lösen und den Lösungen, die wir diskutieren, einen realen Kontext zu geben, beginnen wir mit einer wörtlichen Saga über die Sysops Squad.

Wir verwenden die Sysops Squad-Saga in jedem Kapitel, um die in diesem Buch beschriebenen Techniken und Kompromisse zu veranschaulichen. In vielen Büchern über Software-Architekturen geht es um Neuentwicklungen, aber viele Probleme der realen Welt bestehen in bestehenden Systemen. Deshalb beginnt unsere Geschichte mit der bestehenden Architektur von Sysops Squad, die hier vorgestellt wird.

Penultimate Electronics ist ein großer Elektronikriese, der zahlreiche Einzelhandelsgeschäfte im ganzen Land betreibt. Wenn Kunden Computer, Fernseher, Stereoanlagen und andere elektronische Geräte kaufen, können sie sich für einen Support-Plan entscheiden. Wenn Probleme auftreten, kommen Technikexperten (die Sysops Squad) zu den Kunden nach Hause (oder ins Büro), um Probleme mit dem elektronischen Gerät zu beheben.

Die vier Hauptnutzer der Sysops Squad Ticketing-Anwendung sind folgende:

Administrator

Der Administrator verwaltet die internen Nutzer des Systems, einschließlich der Liste der Experten und ihrer entsprechenden Fähigkeiten, Standorte und Verfügbarkeit. Der Administrator verwaltet auch die gesamte Rechnungsstellung für die Kunden, die das System nutzen, und pflegt statische Referenzdaten (z. B. unterstützte Produkte, Name-Wert-Paare im System usw.).

Kunde

Der Kunde registriert sich für den Sysops Squad-Service und pflegt sein Kundenprofil, die Supportverträge und die Rechnungsinformationen. Die Kunden geben Problemtickets in das System ein und füllen auch Umfragen aus, nachdem die Arbeit abgeschlossen wurde.

Sysops Squad Experte

Experten werden Problemtickets zugewiesen und beheben Probleme auf der Grundlage des Tickets. Sie interagieren auch mit der Wissensdatenbank, um nach Lösungen für Kundenprobleme zu suchen und Notizen zu Reparaturen einzugeben.

Manager

Der Manager behält den Überblick über den Betrieb der Problemtickets und erhält operative und analytische Berichte über das gesamte Problemticketsystem von Sysops Squad.

Nonticketing Workflow

Zu den Nicht-Ticket-Workflows gehören die Aktionen, die Administratoren, Manager und Kunden durchführen, die sich nicht auf ein Problemticket beziehen. Diese Arbeitsabläufe werden im Folgenden beschrieben:

1. Sysops Squad-Experten werden im System durch einen Administrator hinzugefügt und gepflegt, der ihren Standort, ihre Verfügbarkeit und ihre Fähigkeiten eingibt.

2. Die Kunden melden sich beim Sysops Squad-System an und haben je nach gekauftem Produkt mehrere Supportpläne.

3. Die Kunden erhalten automatisch eine monatliche Rechnung auf der Grundlage der in ihrem Profil enthaltenen Kreditkarteninformationen. Die Kunden können die Abrechnungshistorie und die Kontoauszüge über das System einsehen.

4. Die Manager/innen fordern verschiedene operative und analytische Berichte an und erhalten diese auch, darunter Finanzberichte, Berichte über die Leistung von Expert/innen und Ticketing-Berichte.

Ticketing Workflow

Der Ticketing-Workflow beginnt, wenn ein Kunde ein Problemticket in das System eingibt, und endet, wenn der Kunde nach der Reparatur die Umfrage ausfüllt. Dieser Arbeitsablauf ist wie folgt skizziert:

1. Kunden, die den Support-Plan gekauft haben, geben ein Problemticket über die Sysops Squad-Website ein.

2. Sobald ein Problemticket in das System eingegeben wird, ermittelt das System anhand von Fähigkeiten, aktuellem Standort, Servicegebiet und Verfügbarkeit, welcher Sysops Squad-Experte am besten für den Auftrag geeignet wäre.

3. Sobald das Problemticket zugewiesen ist, wird es auf eine spezielle App auf dem mobilen Gerät des Sysops Squad-Experten hochgeladen. Der Experte wird außerdem per Textnachricht darüber informiert, dass er ein neues Problemticket hat.

4. Der Kunde wird per SMS oder E-Mail (je nach Profilpräferenz) benachrichtigt, dass der Experte auf dem Weg ist.

5. Der Experte verwendet die benutzerdefinierte mobile Anwendung auf seinem Telefon, um die Ticketinformationen und den Standort abzurufen. Der Sysops Squad-Experte kann über die mobile App auch auf eine Wissensdatenbank zugreifen, um herauszufinden, was in der Vergangenheit getan wurde, um das Problem zu beheben.

6. Sobald der Experte das Problem behoben hat, markiert er das Ticket als "vollständig". Der Experte der Sysops-Gruppe kann dann Informationen über das Problem hinzufügen und die Wissensdatenbank reparieren.

7. Nachdem das System die Benachrichtigung erhalten hat, dass das Ticket vollständig ist, sendet es eine E-Mail an den Kunden mit einem Link zu einer Umfrage, die der Kunde dann ausfüllt.

8. Das System erhält die ausgefüllte Umfrage vom Kunden und zeichnet die Umfragedaten auf.

Ein schlechtes Szenario

Mit der Problemticket-Anwendung von Sysops Squad lief es in letzter Zeit nicht gut. Das aktuelle Trouble-Ticket-System ist eine große, monolithische Anwendung, die vor vielen Jahren entwickelt wurde. Die Kunden beschweren sich darüber, dass die Berater nie erscheinen, weil die Tickets verloren gegangen sind, und dass oft der falsche Berater auftaucht, um etwas zu reparieren, von dem er keine Ahnung hat. Die Kunden haben sich auch darüber beschwert, dass das System nicht immer verfügbar ist, um neue Problemtickets einzugeben.

Auch Veränderungen sind in diesem großen Monolithen schwierig und riskant. Wenn eine Änderung vorgenommen wird, dauert sie in der Regel zu lange und etwas anderes geht in der Regel kaputt. Aufgrund von Zuverlässigkeitsproblemen "friert" das System der Sysops Squad häufig ein oder stürzt ab, was dazu führt, dass alle Anwendungsfunktionen zwischen fünf Minuten und zwei Stunden nicht verfügbar sind, während das Problem identifiziert und die Anwendung neu gestartet wird.

Wenn nicht bald etwas unternommen wird, wird Penultimate Electronics gezwungen sein, den sehr lukrativen Geschäftsbereich der Supportverträge aufzugeben und alle Sysops Squad-Administratoren, Experten, Manager und IT-Entwicklungsmitarbeiter - einschließlich der Architekten - zu entlassen.

Sysops Squad Architektonische Komponenten

Das monolithische System für die Sysops Squad-Anwendung übernimmt die Ticketverwaltung, die Betriebsberichterstattung, die Kundenregistrierung und die Rechnungsstellung sowie allgemeine Verwaltungsfunktionen wie die Benutzerverwaltung, die Anmeldung und die Pflege der Expertenfähigkeiten und -profile. Abbildung 1-3 und die dazugehörige Tabelle 1-1 veranschaulichen und beschreiben die Komponenten der bestehenden monolithischen Anwendung (der ss. Teil des Namensraums gibt den Anwendungskontext von Sysops Squad an).

Abbildung 1-3. Komponenten innerhalb der bestehenden Sysops Squad-Anwendung

Tabelle 1-1. Vorhandene Komponenten der Sysops Squad

Komponente	Namensraum	Verantwortung
Anmeldung	ss.login	Interne Benutzer- und Kundenanmeldung und Sicherheitslogik
Bezahlung der Rechnung	ss.billing.payment	Monatliche Kundenabrechnung und Kreditkarteninformationen
Abrechnungshistorie	ss.billing.history	Zahlungsverhalten und frühere Rechnungsauszüge
Kundenbenachrichtigung	ss.customer.notification	Benachrichtigung des Kunden über Rechnungen, allgemeine Informationen
Kundenprofil	ss.customer.profile	Kundenprofil pflegen, Kundenregistrierung
Expertenprofil	ss.expert.profile	Pflege des Expertenprofils (Name, Standort, Fähigkeiten, etc.)
KB Wartung	ss.kb.maintenance	Artikel in der Wissensdatenbank pflegen und einsehen
KB-Suche	ss.kb.search	Abfragemaschine für die Suche in der Wissensbasis
Melden	ss.reporting	Alle Berichte (Experten, Tickets, Finanzen)
Ticket	ss.ticket	Ticket-Erstellung, -Wartung, -Erledigung, gemeinsamer Code
Ticket zuweisen	ss.ticket.assign	Finde einen Experten und weise das Ticket zu
Ticket benachrichtigen	ss.ticket.notify	Benachrichtige den Kunden, dass der Experte auf dem Weg ist
Ticket-Route	ss.ticket.route	Sende das Ticket an die App für das mobile Gerät des Experten
Unterstützungsvertrag	ss.supportcontract	Supportverträge für Kunden, Produkte im Plan
Umfrage	ss.survey	Pflege der Umfragen, Erfassung und Aufzeichnung der Umfrageergebnisse
Umfrage benachrichtigen	ss.survey.notify	Umfrage per E-Mail an den Kunden senden
Templating für Umfragen	ss.survey.templates	Führe verschiedene Erhebungen je nach Art der Dienstleistung durch
Wartung durch den Benutzer	ss.users	Interne Benutzer und Rollen pflegen

Diese Komponenten werden in den folgenden Kapiteln verwendet, um verschiedene Techniken und Kompromisse zu veranschaulichen, wenn es darum geht, Anwendungen in verteilteArchitekturen einzubinden.

Sysops Squad Datenmodell

Die Anwendung Sysops Squad mit ihren verschiedenen Komponenten, die in Tabelle 1-1 aufgeführt sind, verwendet ein einziges Datenbankschema, in dem alle Tabellen und der dazugehörige Datenbankcode gespeichert sind. In der Datenbank werden Kunden, Benutzer, Verträge, Rechnungen, Zahlungen, die Wissensdatenbank und Kundenumfragen gespeichert. Die Tabellen sind in Tabelle 1-2 aufgeführt und das ER-Modell ist in Abbildung 1-4 dargestellt.

Abbildung 1-4. Datenmodell innerhalb der bestehenden Sysops Squad-Anwendung

Tabelle 1-2. Vorhandene Sysops Squad-Datenbanktabellen

Tabelle	Verantwortung
Kunde	Einrichtungen, die Sysops Unterstützung benötigen
Kunden_Benachrichtigung	Benachrichtigungspräferenzen für Kunden
Umfrage	Eine Umfrage zur Kundenzufriedenheit nach dem Support
Frage	Fragen in einer Umfrage
Umfrage_Frage	Der Umfrage wird eine Frage zugewiesen
Umfrage_Verwaltet	Umfragefrage wird dem Kunden zugewiesen
Umfrage_Antwort	Die Antwort eines Kunden auf die Umfrage
Abrechnung	Abrechnungsinformationen für den Supportvertrag
Vertrag	Ein Vertrag zwischen einem Unternehmen und Sysops für Unterstützung
Zahlungsmethode	Unterstützte Zahlungsarten für die Bezahlung
Zahlung	Zahlungen für Rechnungen verarbeitet
SysOps_User	Die verschiedenen Benutzer in Sysops
Profil	Profilinformationen für Sysops Benutzer
Experten_Profil	Profile von Experten
Expertise	Verschiedene Kompetenzen innerhalb der Sysops
Standort	Vom Experten bediente Standorte
Artikel	Artikel für die Wissensdatenbank
Tag	Tags auf Artikel
Schlüsselwort	Schlüsselwort für einen Artikel
Artikel_Tag	Mit den Artikeln verknüpfte Tags
Artikel_Stichwort	Tabelle für Schlüsselwörter und Artikel verbinden
Ticket	Von Kunden gestellte Support-Tickets
Ticket_Typ	Verschiedene Arten von Tickets
Ticket_Geschichte	Die Geschichte der Support-Tickets

Das Sysops-Datenmodell ist ein Standard-Datenmodell der dritten Normalform mit nur wenigen gespeicherten Prozeduren oder Triggern. Es gibt jedoch eine ganze Reihe von Ansichten, die hauptsächlich von der Komponente Reporting verwendet werden. Wenn das Architekturteam versucht, die Anwendung aufzubrechen und zu einer verteilten Architektur überzugehen, muss es mit dem Datenbankteam zusammenarbeiten, um die Aufgaben auf der Datenbankebene zu erledigen. Anhand dieses Aufbaus von Datenbanktabellen und -ansichten werden im Laufe des Buches verschiedene Techniken und Kompromisse erörtert, um die Aufgabe der Aufteilung der Datenbank zu bewältigen.