Die Kunst der Erstellung von Architekturdiagrammen

In jedem Softwareprojekt, an dem wir beteiligt sind, kann es irgendwann notwendig sein, Architekturdiagramme zu erstellen. Unabhängig davon, ob wir uns an ein formales Architekturmodell halten (z.B. Kruchten 4+1, Rozanski & Woods, etc.), besteht die Notwendigkeit, einige Teile der Anwendung durch die Erstellung von Diagrammen zu dokumentieren. In der Softwarearchitektur werden solche Diagramme in Übereinstimmung mit Sichten erstellt, die sich auf einen bestimmten Gesichtspunkt beziehen, der Teil eines Modells sein könnte, aber in diesem Artikel ziehe ich es vor, bei dem Begriff Architekturdiagramm zu bleiben und nicht sehr formal zu sein; alle anderen Aspekte sollen hier nicht behandelt werden.

Aufgrund meiner Erfahrung als Softwarearchitekt und technischer Trainer gibt es eine Menge Diskrepanzen zwischen Projekten und innerhalb des Projektteams von Entwickler zu Entwickler in der Art und Weise, wie Architekturdiagramme erstellt werden. Ich habe viele Probleme in Bezug auf Inkonsistenz, Fragmentierung und Granularität der gerenderten Informationen und das Aussehen der Diagramme gesehen. Im Vergleich zu einem Architekturmodell, das formal und standardisiert sein muss, sind die Diagramme nicht unbedingt formalisiert oder folgen einem bestimmten Standard.

Allerdings müssen Diagramme selbstbeschreibend, konsistent, genau genug und mit dem Code verbunden sein. Deshalb ist es wichtig, dass sich jeder Architekt oder Softwareentwickler bei der Erstellung von Architekturdiagrammen auf mehrere Richtlinien stützt, da sie die gemeinsame Grundlage für die Kommunikation der Anwendungsarchitektur im Laufe der Zeit (z.B. Struktur, Elemente, Beziehungen, Eigenschaften, Prinzipien) und zwischen verschiedenen Interessengruppen mit unterschiedlichen technischen Hintergründen und Anliegen bilden.

Gängige Fallstricke bei der Erstellung von Architekturdiagrammen

Bevor ich mich näher mit möglichen Problemen befasse, möchte ich eine Analogie zu einer englischen Redewendung anführen, die besagt, dass „ein Bild mehr als tausend Worte sagt“. Laut dieser Wiki-Erklärung „bezieht sich diese Redewendung auf die Vorstellung, dass ein komplexer Gedanke mit einem einzigen Standbild vermittelt werden kann oder dass ein Bild eines Themas seine Bedeutung oder Essenz effektiver vermittelt als eine Beschreibung“. Dasselbe Konzept gilt für ein architektonisches Diagramm: Wenn es mehr Fragen als Antworten aufwirft, ist das Diagramm nicht gut erstellt. Lassen Sie nicht zu, dass ein architektonisches Diagramm Tausende von Worten oder Erläuterungen erfordert!

Beispiel für ein ungeeignetes architektonisches Diagramm. Es weist die meisten der unten beschriebenen Probleme auf

Lassen Sie uns nun eine Liste von Fallstricken durchgehen, die den Prozess der ordnungsgemäßen Erstellung von Architekturdiagrammen behindern können.

Was bedeutet ein Kasten oder eine Form?

• Die Verwendung jeglicher Art von Kasten oder Form, die nicht ordnungsgemäß dokumentiert ist, kann zu verschiedenen Interpretationen führen. Es könnte entweder mit einem Teil der Daten, einem Bündel von Code oder einem Prozess in Verbindung gebracht werden. Schon ein einfacher Kasten in einem Diagramm kann mehrere Zweifel aufkommen lassen, und es ist sehr wichtig, diese zu vermeiden, indem in der Legende des Diagramms ausdrücklich Angaben zur Bedeutung des Kastens oder der Form gemacht werden.

Was bedeuten die verschiedenen Ränder einer Form?

• Jeder Rand einer Form (z. B. gestrichelt, gepunktet usw.) kann bei einem schlechten Diagramm missverstanden werden. Bezieht sich eine bestimmte Umrandung auf einen bestimmten Komponententyp (z. B. bezieht sich eine gestrichelte Linie auf einen Container, einen Microservice, eine Schicht usw.), oder handelt es sich lediglich um die Vorliebe des Designers für ein reichhaltiges Erscheinungsbild? Vermeiden Sie solche Verwirrungen, indem Sie bei der Auswahl mehrerer oder nicht standardisierter Kanten genaue Angaben im Legendendiagramm machen.

Was bedeutet eine Linie oder ein Pfeil?

• Eine Linie oder ein Pfeil kann entweder als Datenfluss (z. B. Daten fließen von System A zu System B) oder als Beziehung zwischen Elementen (z. B. Komponente A hängt von Komponente B ab) interpretiert werden. In den meisten Fällen laufen die Beziehungen oder Datenflüsse, die durch Pfeile dargestellt werden, nicht in dieselben Richtungen zusammen, und es ist wichtig, dies in der Diagrammlegende explizit zu vermerken.

Welchen Typ von Kommunikation/Assoziation zeigt eine Linie oder ein Pfeil an?

• Selbst wenn sich die Linie auf einen Datenfluss oder eine Beziehung zwischen Komponenten bezieht, muss der Typ der Kommunikation (z. B. im Falle eines Datenflusses) oder der Typ der Assoziation (z. B. im Falle einer Beziehung), der durch diese Linie oder diesen Pfeil dargestellt wird, detailliert angegeben werden. Stellt die Linie beispielsweise einen Datenfluss dar, kann die Kommunikation synchron oder asynchron sein, bezieht sich die Linie jedoch auf eine Beziehung, kann diese durch eine Abhängigkeit, Vererbung, Implementierung usw. dargestellt werden. Alle diese Details müssen in der Legende des Diagramms enthalten sein.

Was bedeutet diese Farbe?

• Ein „perrot“-Policolor-Diagramm (z.B. mehrere Farben für Kästchen und Linien) ohne eine dokumentierte Absicht kann zahlreiche Fragen aufwerfen (z.B. warum sind einige Kästchen grün und andere rot? Warum sind einige Linien schwarz und andere blau?). Das Farbschema ist in einem Diagramm weniger wichtig, und die Verwendung einer großen Anzahl von Farben bringt nicht allzu viel zusätzlichen Inhalt oder wertvolle Informationen. Ein Diagramm kann auch selbsterklärend und gut gestaltet sein, wenn nur schwarze und weiße Farben verwendet werden, es sei denn, es besteht die zwingende Notwendigkeit, bestimmte Teile des Diagramms durch die Verwendung von unterscheidbaren Farben hervorzuheben. In jedem Fall ist es immer besser, sich bei den verwendeten Farben an die Einfachheit zu halten, aber wenn dies nicht der Fall ist, sollte man nicht vergessen, die Wahl genau zu erläutern.

Fehlende Beziehungen zwischen Diagrammelementen oder isolierten Einheiten

• Fehlende Beziehungen zwischen Elementen oder isolierten Einheiten in einem Diagramm können ein Hinweis auf Unvollständigkeit sein. Sowohl aus struktureller als auch aus verhaltensbezogener Sicht sollte jedes Element oder jede Entität auf einen anderen Teil des Systems, der durch ein anderes Element dargestellt wird, angewiesen sein bzw. eine Beziehung zu ihm haben (dargestellt durch eine Linie oder einen Pfeil).

Missverständliche/undokumentierte Akronyme oder zu vage/generische Begriffe

• Bei der Beschriftung eines Elements in einem Diagramm wird empfohlen, keine irreführenden oder undokumentierten Akronyme zu verwenden, die Verwirrung stiften könnten. Eine bloße Buchstabenfolge (z.B. TFH, RBPM) bedeutet nichts, wenn sie nicht auf dem Diagrammelement oder besser noch in der Diagrammlegende erklärt wird (z.B. TFH – ticket feed handler, RBPM – rates business process manager).

• Ein weiteres Merkmal bei der Benennung von Diagrammelementen sind extrem vage oder generische Begriffe (z.B. Geschäftslogik, Integrationslogik), die nicht allzu viele wertvolle Informationen liefern, weil ihre Namen nicht richtig selbstbeschreibend sind. Dieses Problem könnte auch auf der Code-Ebene liegen, und der Vorschlag wäre, immer selbsterklärende und aussagekräftige Namen zu verwenden, indem man die Prinzipien des sauberen Codes befolgt.

Technologien, Frameworks, Programmier- oder Skriptsprachen, IDE oder Entwicklungsmethodik in Diagrammen betonen

• Das architektonische Design ist nicht mit einer Technologie, einem Framework, einer Programmier- oder Skriptsprache, einer IDE oder einer Entwicklungsmethodik verbunden oder basiert grundsätzlich darauf. All dies kommt später im Prozess hinzu, um den Aufbau der Architektur zu unterstützen, aber es ist nicht der zentrale Punkt. Sie sollten nicht in den Diagrammen enthalten sein, sondern in der Architekturbeschreibung angegeben werden, einschließlich der Gründe für ihre Auswahl.

Laufzeit- und statische Elemente im gleichen Diagramm mischen

• Laufzeitelemente (z.B. Threads, Prozesse, virtuelle Maschinen, Container, Dienste, Firewalls, Daten-Repositories usw.) sind zur Kompilierzeit nicht vorhanden und es wird empfohlen, diese Elemente nicht mit statischen Elementen (z.B. Komponenten, Pakete, Klassen) im gleichen Diagramm zu mischen. Es gibt spezielle Diagrammtypen (z.B. Gleichzeitigkeitsdiagramm, Bereitstellungsdiagramm), die sich in erster Linie auf Laufzeitelemente konzentrieren, und es ist wichtig, zwischen diesen beiden Elementkategorien zu unterscheiden und ihre Vermischung so weit wie möglich zu vermeiden.

Machen Sie Annahmen wie „Ich werde dies verbal beschreiben“ und „Ich werde es später erklären“

• Alles, was nicht durch das Diagramm selbst beschrieben wird, fehlt, und es gibt keinen Raum für verbale Details zur Ergänzung eines Diagramms. Warum? Weil alle Erklärungen, die mündlich erwähnt, aber nicht im Diagramm festgehalten wurden, verloren gehen und später, wenn andere Beteiligte (z. B. Entwickler, Architekten) das Diagramm lesen, werden sie diese Erklärungen nicht kennen. Versuchen Sie, alle notwendigen Details in ein Diagramm aufzunehmen, um weiteren Klärungsbedarf zu vermeiden.

Konfliktierende Detailebenen oder gemischte Abstraktionen

• Das Hinzufügen von Elementen verschiedener Abstraktionsebenen im selben Diagramm kann zu Konflikten führen, da sie aus unterschiedlichen Perspektiven betrachtet werden. So kann beispielsweise das Hinzufügen von Komponenten zu einem Architekturkontextdiagramm oder von Klassen zu einem Deployment-Diagramm den Zweck des Diagramms selbst verfälschen. Versuchen Sie bei der Erstellung eines Diagramms, auf der gleichen Abstraktionsebene zu bleiben.

Unübersichtliche oder zu vage Diagramme, die versuchen, zu viele oder zu wenige Details darzustellen

• „Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher“ ist ein bekanntes Zitat von Albert Einstein. Dies gilt auch für Architekturdiagramme; die Ebene und die Granularität der erfassten Informationen sollte sinnvoll gewählt werden. Dies ist keine einfache Sache; es hängt vom verwendeten Architekturmodell, der Erfahrung des Architekten und der Komplexität des Systems ab.

Richtlinien, die bei der Erstellung von Architekturdiagrammen zu beachten sind

Neben den oben genannten Fallstricken, die Teil einer voraussetzungsvollen Checkliste sein müssen, um sie zu vermeiden, gibt es auch allgemeine Richtlinien für die richtige Erstellung von Diagrammen:

Wählen Sie die optimale Anzahl von Diagrammen

• Wie Philippe Kruchten sagte, „Architektur ist ein komplexes Biest. Die Verwendung einer einzigen Blaupause zur Darstellung von Architektur führt zu einem unverständlichen semantischen Durcheinander.“ Um moderne Systeme zu dokumentieren, können wir nicht nur eine Art von Diagramm verwenden, aber bei der Erstellung von Architekturdiagrammen ist es nicht immer einfach, welche Diagramme zu wählen und wie viele davon zu erstellen sind. Bevor eine Entscheidung getroffen wird, müssen mehrere Faktoren berücksichtigt werden, z. B. die Art und die Komplexität der Architektur, die Fähigkeiten und die Erfahrung des Softwarearchitekten, die verfügbare Zeit, der Arbeitsaufwand für die Pflege der Diagramme und die Frage, was für die Belange der Beteiligten sinnvoll oder nützlich ist. So wird ein Netzwerkingenieur wahrscheinlich ein explizites Netzwerkmodell mit Hosts, Kommunikationsanschlüssen und Protokollen sehen wollen; ein Datenbankadministrator interessiert sich dafür, wie das System die Daten manipuliert, verwaltet und verteilt, usw. Basierend auf all diesen Aspekten ist es empfehlenswert, die optimale Anzahl von Diagrammen zu wählen, egal wie hoch diese Zahl ist.
• Wenn es zu wenig Diagramme gibt (z.B. Unterdokumentation), könnten Teile der Architektur versteckt oder undokumentiert sein; andererseits, wenn es zu viele gibt (z.B.

Bewahren Sie die strukturelle und semantische Konsistenz der Diagramme

• Jedes Diagramm sollte mit den anderen in Bezug auf Kästchen, Formen, Ränder, Linien, Farben usw. konsistent sein. Das strukturelle Erscheinungsbild sollte gleich sein, und jeder Beteiligte sollte keine Schwierigkeiten haben, Diagramme zu verstehen, die von verschiedenen Entwicklern innerhalb eines Teams erstellt wurden. Idealerweise sollte ein gemeinsames Diagrammwerkzeug verwendet werden, das projektübergreifend eingesetzt werden kann.
• Aus semantischer Sicht sollten alle diese Diagramme regelmäßig mit den neuesten Codeänderungen und untereinander synchronisiert werden, da eine Änderung in einem Diagramm Auswirkungen auf andere haben kann. Dieser Prozess kann manuell oder automatisch durch die Verwendung eines Modellierungswerkzeugs ausgelöst werden. Letzteres ist der bevorzugte Mechanismus, aber das hängt von Projekt zu Projekt ab. In jedem Fall geht es darum, die Konsistenz zwischen Diagrammen und Code zu wahren, unabhängig von der Methode oder dem Werkzeug. Simon Brown sagte: „Diagramme sind für die Architekturverbesserung nicht nützlich, wenn sie nicht mit dem Code verbunden sind“, was die Idee der semantischen Konsistenz unterstreicht.

Verhindern Sie die Fragmentierung von Diagrammen

• Das Vorhandensein mehrerer Diagramme kann die Architekturbeschreibung schwer verständlich machen, aber auch einen beträchtlichen Aufwand bei der Pflege bedeuten. Als Nebeneffekt kann es zu einer Fragmentierung kommen (z.B. zwei oder mehr Diagramme veranschaulichen dasselbe Qualitätsmerkmal – Leistung, Skalierbarkeit, etc. – aber jedes von ihnen ist einzeln unvollständig). In solchen Fällen wird empfohlen, entweder die Diagramme zu entfernen, die keine relevanten Qualitätsattribute widerspiegeln (die mit architektonisch bedeutsamen Anforderungen verbunden sind), oder, noch besser, die Diagramme zusammenzuführen (z.B. Gleichzeitigkeit und Bereitstellung).

Die Rückverfolgbarkeit über Diagramme hinweg aufrechterhalten

• Es ist auch wichtig, die Historie überprüfen zu können, Vergleiche zwischen verschiedenen Diagrammversionen anstellen zu können und leicht zu einer früheren Version zurückkehren zu können. Die Verwendung eines Modellierungswerkzeugs, das dies nicht zulässt, kann ein Hindernis darstellen. Die neuesten Trends in der Branche setzen auf die Verwendung einer einfachen und intuitiven Klartextsprache, um daraus die Diagramme zu generieren, was das Problem der Rückverfolgbarkeit zu lösen scheint. Ein weiterer Vorteil eines solchen Ansatzes ist, dass er implizit eine homogene strukturelle Konsistenz zwischen den Diagrammen sicherstellt.

Fügen Sie Legenden zu den Architekturdiagrammen hinzu

• Wenn Sie keine standardisierte Architekturbeschreibungssprache (z.B. UML, ArchiMate) verwenden, sollten Sie jedes Teil des Diagramms in der Legende detailliert beschreiben (z.B. Kästchen, Formen, Grenzen, Linien, Farben, Akronyme usw.).
• Wenn dies nicht der Fall ist, genügt es, in der Legende die Architekturbeschreibungssprache als Schlüssel hinzuzufügen, und es besteht keine Notwendigkeit für zusätzliche Erklärungen, da jeder Leser die Besonderheiten der Sprache nachvollziehen kann, um das Diagramm zu verstehen.

Wirkt sich die Architekturbeschreibungssprache (z.B. UML, ArchiMate, usw.) aus?

Es gibt viele Meinungen darüber, welche die richtige Beschreibungssprache für das Projekt ist. Einige Leute könnten argumentieren, dass UML starr und nicht flexibel genug ist, um den architektonischen Entwurf zu modellieren, ein Standpunkt, dem ich zustimme. Dennoch kann sie in manchen Fällen mehr als ausreichend sein, um die Grundlagen einer Architektur zu dokumentieren, ohne sich auf UML-Erweiterungsfunktionen wie Profile und Stereotypen zu verlassen. Ein Blick auf andere Beschreibungssprachen zeigt, dass ArchiMate im Vergleich zu UML leistungsfähiger und besser für die Modellierung von Unternehmenssystemen geeignet ist; es gibt auch BPMN, das speziell auf Geschäftsprozesse ausgerichtet ist, usw. Die Vergleiche lassen sich fortsetzen, aber ich habe nicht die Absicht, eine tiefgreifende Überprüfung vorzunehmen, da dies nicht das Ziel dieses Artikels ist.

Eine Architekturbeschreibungssprache zu haben, die umfassend und flexibel genug ist, ist ein großer Schritt nach vorn, und dies sollte ein solides Kriterium bei der Auswahl sein. Aber aus meiner Sicht liegt die eigentliche Ursache woanders und hängt damit zusammen, dass Architekturdokumentation überhaupt nicht erstellt wird. Die Leute finden es oft langweilig, nutzlos oder sinnlos, sie zu erstellen. Die Zahl der Softwareprojekte ohne oder mit unzureichender Dokumentation ist enorm. Ich glaube nicht, dass sich die Menschen intensiv mit der Erstellung von Architekturdiagrammen befassen, wenn sie eine ungeeignete Beschreibungssprache verwenden, und wenn sie diese durch eine bessere ersetzen würden, wären die Ergebnisse ganz anders. Nein, die Menschen erstellen keine Architekturdokumentation (einschließlich Architekturdiagrammen), und was noch schlimmer ist, die meisten von ihnen haben keine Ahnung, wie man sie richtig erstellt. Das sind die Dinge, mit denen wir uns zuerst befassen müssen – um zu verstehen, warum Dokumentation wichtig ist und wie man sie richtig erstellt (durch Schulung von Software-Ingenieuren); dann ergibt sich die Auswahl geeigneter Werkzeuge von selbst.

Wie können Diagramme auf dem neuesten Stand gehalten werden, wenn das System entwickelt wird und sich Änderungen an der Architektur ergeben

Es gibt einige Ansätze, um Diagramme auf dem neuesten Stand zu halten; im Folgenden werde ich drei davon erläutern. Die erste und einfachste Möglichkeit besteht darin, Diagramme automatisch aus dem Quellcode zu generieren, der die Grundwahrheit darstellt. Damit ist gewährleistet, dass alle Diagramme mit dem Code konsistent sind. Leider ist dies mit den vorhandenen Werkzeugen noch nicht vollständig möglich (zumindest meines Wissens), da die aktuellen Werkzeuge keine genauen und aussagekräftigen Diagramme nur auf der Grundlage des Quellcodes erstellen können, ohne dass ein erheblicher manueller Eingriff erforderlich ist. Len Bass sagte: „Die ideale Entwicklungsumgebung ist eine, für die die Dokumentation im Wesentlichen kostenlos auf Knopfdruck verfügbar ist“, was implizit eine automatische Generierung der Diagramme bedeutet, aber wir sind noch nicht an diesem Punkt angelangt.

Der zweite Ansatz wäre, zunächst die Diagramme mit einem speziellen Werkzeug zu entwerfen, das dann die Quellcode-Skelette (z.B. Komponenten/Pakete mit Grenzen, APIs) generiert, die später von den Entwicklern zum Ausfüllen des Codes verwendet werden. Auf diese Weise muss jede Änderung in der Architektur vom Diagramm selbst ausgelöst werden, wodurch das Codeskelett automatisch neu generiert oder aktualisiert werden kann.

Im letzten Fall müssen die Diagramme jedes Mal manuell aktualisiert werden, wenn eine neue Funktion implementiert wird, die Auswirkungen auf das Architekturdesign hat. Um sicher zu sein, dass sich alle Codeänderungen in den Diagrammen widerspiegeln, wird empfohlen, dass die Aktualisierung der Diagramme Teil der Definition von done im Entwicklungsprozess ist. Dieses Szenario ist weniger empfehlenswert, da es leicht zu veralteten oder inkonsistenten Diagrammen führen kann (z.B. vergessen Entwickler oft oder sind nicht in der Stimmung, Diagramme zu aktualisieren), was leider immer noch in der Mehrzahl der Projekte passiert.

Unter Berücksichtigung der vorhandenen Werkzeuge empfehle ich einen Mix; eine Mischung aus automatischer und manueller Diagrammerstellung. Versuchen Sie zum Beispiel, Diagramme automatisch zu erstellen, die von Werkzeugen, die auf dem Quellcode basieren, vernünftig wiedergegeben werden können, ohne zu viel Rauschen (z.B. zu unübersichtliche oder sinnlose Informationen). In diese Kategorie können wir entweder Diagramme mit einem hohen Grad an Volatilität (z. B. anfälliger für häufige Änderungen in der Entwicklung, normalerweise mit geringerer Abstraktion) oder, im Gegenteil, statische Diagramme einordnen. Einige dieser Diagramme können sich auf Kontextdiagramme, Referenzarchitekturdiagramme, Paketdiagramme, Klassendiagramme, Entitätsdiagramme usw. beziehen. In manchen Fällen ist jedoch allein anhand des Quellcodes nicht ersichtlich, wie das System bestimmte Qualitätsmerkmale erfüllt (z. B. Verfügbarkeit, Skalierbarkeit, Leistung), so dass die automatische Erstellung von Diagrammen keine ausreichende Option darstellt. Sie muss durch manuell modellierte Diagramme ergänzt werden. Einige Beispiele für solche Diagramme sind Sequenzdiagramme, Zustandsdiagramme, Gleichzeitigkeitsdiagramme, Bereitstellungsdiagramme, Betriebsdiagramme usw.

Welche Komplikationen (oder Vereinfachungen) ergeben sich für Architekturdiagramme im Umgang mit modernen Architekturen (z. B. Microservices)?

Microservices oder jeder andere moderne Architekturstil (z.B. serverlos, ereignisgesteuert) bestimmt nur die Struktur des Systems, wie die Komponenten miteinander kommunizieren (z.B. Beziehungen zwischen ihnen) und welche Prinzipien sie bestimmen. Ich persönlich glaube nicht, dass der Architekturstil das Grundprinzip oder die Konzepte für die Erstellung der Diagramme (und implizit der Architekturbeschreibung) ändern sollte, und auch nicht, was sie erfassen sollten. Wenn wir jedoch über moderne Systemarchitekturen sprechen, die im Vergleich zu alten und klassischen Systemen (z.B. Monolithen) in der Regel einen höheren Komplexitätsgrad aufweisen, haben diese definitiv einen Einfluss auf die Architekturbeschreibung und implizit auf die Diagramme, und zwar in dem Sinne, dass es mehrere Überlegungen zu beachten gilt. Solche Überlegungen können sich auf das Verständnis der Anzahl verteilter Komponenten (z. B. verteilte Microservices), den Typ jeder Komponente, die Art und Weise, wie die Komponenten miteinander kommunizieren (z. B. Grenzen, APIs, Nachrichten), ihren Lebenszyklus und den Eigentümer jeder Komponente beziehen.

Unter Berücksichtigung all dieser Aspekte sollten standardmäßig Sichten berücksichtigt werden, die die Systemdekomposition, die Entwicklung, die Bereitstellung und die Betriebsfähigkeit erfassen. Stellen Sie sich zum Beispiel ein System mit einer beeindruckenden Anzahl von Microservices vor; in einem solchen Fall könnte die Anzahl der Diagramme erheblich ansteigen, da jeder Microservice am Ende einen eigenen Satz von Diagrammen haben könnte. Probleme in Bezug auf Konsistenz (z. B. die Änderung der API eines Dienstes wirkt sich auf andere X-Dienste aus, so dass alle betroffenen Diagramme aktualisiert werden müssen), Fragmentierung (z. B. hohe Verfügbarkeit oder Leistung zwischen verteilten Diensten wird nicht in einem Diagramm konsolidiert) oder übergreifende Belange (z. B. wer ist für die konsolidierte Darstellung von Aspekten wie Überwachung oder Sicherheit über alle Systemelemente hinweg zuständig) sind möglicherweise nicht leicht zu lösen. Darüber hinaus können sich Herausforderungen im Zusammenhang mit der Koexistenz und Zusammenarbeit von Teams während der Projektentwicklung und sogar danach ergeben, um das Projekt aufrechtzuerhalten.

Zusammenfassend lässt sich sagen, dass moderne Systeme mit komplexen Architekturen zusätzliche Probleme mit sich bringen können, die sogar auf der Ebene der Diagramme zu Komplikationen führen können.

Über den Autor

Ionut Balosin ist Softwarearchitekt und unabhängiger technischer Trainer. Er ist regelmäßiger Redner auf Softwareentwicklungskonferenzen und Meetups auf der ganzen Welt und hält dort Präsentationen, Schulungen und Workshops. Weitere Informationen finden Sie auf seiner Website.