Freigeben über

Architekturentwurfsdiagramme

Architekten kommunizieren häufig über Diagramme. Gut gestaltete visuelle Elemente sind ein leistungsfähiges Tool, mit dem Implementierungen, Sicherheitsprüfer und Geschäftsbeteiligte auf einem gemeinsamen mentalen Modell konvergent werden, Risiken früher offenlegen und Überarbeitungen reduzieren können. Um mit Absicht zu kommunizieren, muss ein Architekt Diagrammtypen auswählen und häufig layern, die der Nachrichten-, Zielgruppen- und Lebenszyklusstufe entsprechen.

Letztendlich hängt die Wahl des Architekturdiagramms davon ab, was Sie vermitteln möchten, und die Fragen Ihres Publikums. Architekten verwenden mehrere Arten von Diagrammen während der gesamten Entwurfsaktivitäten, der Einschränkung der Anforderungen und der Kommunikation der Projektbeteiligten. Erwarten Sie, dass mehrere Diagramme für die Gesamtevisionierung, Entwurfserstellung, Bedrohungsmodellierung, Implementierung, Vorgänge und Governance beibehalten werden.

Diagrammerstellungspraktiken

Effektive Diagramme vermitteln wesentliche Informationen, ohne dass umfangreiche textbezogene Erläuterungen erforderlich sind. Um Mehrdeutigkeit zu vermeiden und eine klare Kommunikation zu gewährleisten, befolgen Sie die folgenden Empfehlungen:

Verwenden Sie Standardnotationen. Verwenden Sie weit anerkannte Symbole, Symbole und Präsentationskonventionen, um eine gute Lesbarkeit und konsistente Interpretation für verschiedene Zielgruppen zu gewährleisten.

Vermeiden Sie mehrdeutige Zeilen. Diagramme zeigen häufig Beziehungen zwischen Entitäten mithilfe von Linien an. Achten Sie darauf, wie Sie diese Beziehungen in allen Diagrammen darstellen.

Verwenden Sie richtungsgerichtete Pfeile. Linien ohne Pfeile machen Beziehungen unklar. Verwenden Sie immer Pfeile, und wenn bidirektionale Kommunikation vorhanden ist, zeigen Sie entweder zwei separate Flüsse (bevorzugt) an oder kommentieren Sie einen einzelnen Pfeil mit Anforderungs-/Antwortnotizen.

Vermeiden Sie bidirektionale Pfeile. Doppelpfeile bedeuten bidirektionale Abhängigkeiten, die Verwirrung erzeugen können. Verwenden Sie einseitige Pfeile, um den Fluss von der initiierenden Komponente (Client) zur Abhängigkeit (Server) darzustellen.

Bezeichnen Sie alles klar. Stellen Sie klare, genaue und aussagekräftige Bezeichnungen für jedes Symbol, jeden Gruppierungscontainer und jede Beziehung bereit. Beschriftungslinien, wenn Beziehungen nicht sofort aus dem Kontext ersichtlich sind.

Konsistenz beibehalten. Verwenden Sie standardisierte Farben, Groß-/Kleinschreibung, Symbole, Symbolgrößen, Linienstärken, Linientypen, Pfeilköpfe und Rahmenarten für ähnliche Elemente. Wenden Sie die gleiche Taxonomie für jedes Diagramm im Lösungssatz an. Zeichnen Sie aus vorhandenen Organisationsstandards oder Taxonomien.

Seien Sie richtig. Während Diagramme Abstraktionen sind, verzichten Sie nicht auf die Genauigkeit, um unnötige Einfachheit zu vermeiden. Stellen Sie beispielsweise keinen PaaS-Dienst in einem Subnetz dar, wenn tatsächlich über einen privaten Endpunkt darauf zugegriffen wird. Ungenauigkeiten in Diagrammen können zu schwerwiegenden Fehlkommunikations- und Implementierungsverzögerungen oder Fehlern führen. Eingestellte Diagramme, die eine aktive Stakeholder-Frage nicht mehr genau beantworten.

Fügen Sie Metadaten ein. Stellen Sie sicher, dass jedes Diagramm Metadaten enthält, die wesentliche Kontexte zu Zweck, Umfang und Bedeutung bieten. Schließen Sie Elemente wie Titel, Beschreibung, Datum der letzten Aktualisierung, Autor, Version und externe Verweise ein. Diese Informationen helfen den Betrachtern, die Absicht und Aktualität des Diagramms zu verstehen. Nachdem ein Diagramm allgemein freigegeben wurde, hilft das Verwalten eines verknüpften Änderungsprotokolls dazu, dass Die Betrachter wissen, was geändert wurde.

Verwenden Sie offizielle Symbole und Dienstnamen. Verwenden Sie bei der Darstellung bestimmter Technologien immer die neuesten offiziellen Symbole und Benennungskonventionen. Gestreckt oder neu einfärben Sie Markenformen beliebig. Ersetzen Sie keine Marketinglogos für konzeptionelle Elemente, z. B. die Verwendung von Herstellerlogos für generische API-Gatewayblöcke .

Hier sind beispielsweise die Symbole für Microsoft-Dienste:

Geben Sie eine Legende an. Wenn Sie z. B. eine Rahmen- oder Liniensemantik einführen, ist ein synchroner Aufruf, während das Gedankenstrich asynchron ist, fügen Sie eine kompakte Legende hinzu.

Design für Barrierefreiheit. Stellen Sie einen ausreichenden Farbkontrast sicher. Verlassen Sie sich nicht ausschließlich auf Farbe, um Typen zu unterscheiden, sondern koppeln Sie stattdessen die Farbe konsistent mit dem Muster.

Layer, nicht überladen. Widerstehen Sie dem Drang, alle Subsysteme, Datenklassifizierungen und Laufzeitpfade in einem einzelnen Diagramm zu codieren. Bereitstellen einer progressiven Offenlegung: Ein Kontextdiagramm führt zu einem Containerdiagramm, das zu einer fokussierten Komponente oder einem Sequenzdiagramm für einen kritischen Anwendungsfall führt.

Versionssteuerelement. Speichern Sie Diagrammquelldateien im selben Repository oder Dokumentationsspeicher wie die anderen versionsierten Ressourcen der Workload.

Typen von Entwurfsdiagrammen

Die Workloadarchitektur ist komplex und multidimensional. Verschiedene Diagrammtypen konzentrieren sich auf bestimmte Aspekte des Systems und bieten gezielte Detailebenen für jede Dimension. Flussdiagramme veranschaulichen beispielsweise den Prozessfluss, während Entitätsbeziehungsdiagramme Beziehungen zwischen Systemkomponenten darstellen.

Die Verwendung verschiedener Diagrammtypen ermöglicht ein umfassendes Verständnis für alle architekturübergreifenden Dimensionen. Dieser Ansatz erleichtert eine effektive Kommunikation, Problemlösung und Entscheidungsfindung zwischen verschiedenen Beteiligten mit unterschiedlichen technischen Hintergründen und Bedenken. Ihre Architekturentscheidungsdatensätze verweisen auf diese Diagramme, um die Entscheidung zu visualisieren.

Die folgenden Typen umfassen allgemeine Kommunikationsartefakte der Cloudarchitektur sowie mehrere mehrwertige Ergänzungen. Die Liste der Diagrammtypen ist nicht vollständig. In der Praxis sind viele Artefakte hybrid oder weiterentwickelt. Um Ihre Workload zu visualisieren, bevorzugen Sie einen minimalen Satz von gezielten Diagrammen, um jeden möglichen Typ zu erstellen. Beginnen Sie breit, progressiv schmal, und wenden Sie dann Szenario und quergeschnittene Ansichten an.

Kontextdiagramm

Ein Kontextdiagramm stellt die Arbeitsauslastung als einzelnes schwarzes Feld in seiner externen Umgebung dar. Es benennt das System, gibt kurz seinen Zweck an und zeigt die externen Personas, upstream- und downstream-Systeme sowie Datenquellen oder Senken an, die mit ihm interagieren. Nur die Kommunikations- oder Integrationspfade auf hoher Ebene werden angezeigt; Die interne Struktur wird absichtlich weggelassen, sodass sich die Zielgruppe auf Bereichsgrenzen und Abhängigkeiten konzentriert, nicht auf die Implementierung. Verlassen Sie sich auf generische Formen für externe Systeme und nicht auf Produktlogos, und schließen Sie immer eine explizite Grenze ein, sodass Leser den Bereich nicht ableiten müssen.

Allgemeines System- oder Containerdiagramm

Ein allgemeines Systemdiagramm bietet eine allgemeine Übersicht über eine gesamte Workload oder einen hauptteilteil innerhalb einer Workload. Er dekompiliert die Arbeitsauslastung in ihre Hauptkomponenten, ihre Beziehungen und den allgemeinen Datenfluss über das System. Pfeile geben die Richtung von Interaktionen und Abhängigkeiten an.

Verwenden Sie dieses Diagramm nach der Kontextausrichtung, um Makrostruktur, Hostingmodelle wie PaaS oder selbstverwaltete und externe Abhängigkeiten verfügbar zu machen. Diese Diagramme eignen sich hervorragend zum Aufbau eines gemeinsamen Verständnisses zwischen den Beteiligten, bevor sie sich eingehender mit technischen Diskussionen auseinandersetzen. Sie sind auch für die Kommunikation von Führungskräften und Stakeholdern nützlich, bei denen allgemeines Verständnis wichtiger ist als technische Details.

Block- oder Funktionsdiagramm

Ein Blockdiagramm unterbricht eine Arbeitsauslastung in wichtige funktionale Funktionen mithilfe von technologieagnostischen Blöcken, wobei sich der Fokus auf die ausgeführte Funktionalität und nicht auf die spezifische Komponente konzentriert.

Beispielsweise kann ein Blockdiagramm auf eine Auftragswarteschlange oder einen Messagingbus verweisen, anstatt eine bestimmte Nachrichtenbustechnologie wie Azure Service Bus oder Apache Kafka anzugeben. Diese Abstraktionsebene hilft dabei, die Struktur, den Datenfluss und den Verarbeitungsfluss eines Systems zu erläutern, ohne das Publikum mit Implementierungsspezifischen zu überwältigen, wodurch es ideal für frühe Diskussionen und Anforderungen der Domänenmodellierung ist.

Komponentendiagramm

Ein Komponentendiagramm baut auf Blockdiagrammen auf, indem generische Funktionsblöcke durch bestimmte Technologien und Integrationspunkte ersetzt werden. Es zeigt eine detaillierte Ansicht, die die konkrete Technologie des Systems und deren Beziehungen, z. B. Client-Server-Interaktionen, kommuniziert. Diese Diagramme dienen als visuelle Materialrechnung für die Architektur, die genau zeigt, welche Technologien implementiert werden.

Bereitstellungsdiagramm

Ein Bereitstellungsdiagramm konzentriert sich auf die Bereitstellung von Infrastruktur, kommerzieller Off-the-Shelf-Software (COTS) und benutzerdefiniertem Code in der Hostingumgebung. Es zeigt die Zuordnung zwischen Softwarekomponenten und der physischen oder virtuellen Infrastruktur, die sie hosten.

Diese Diagramme sind nützlich für die Planung von DevOps, die Umgebungseinrichtung und das Verständnis der betrieblichen Aspekte der Architektur. Sie helfen Teams beim Visualisieren von Skalierungsgrenzen, Bereitstellungseinheiten, Infrastrukturabhängigkeiten und Umgebungen.

Datenflussdiagramm (DFD)

Ein Datenflussdiagramm (DATA-Flow Diagram, DFD) veranschaulicht, wie Daten verschoben, transformiert, gespeichert und das System beendet werden. Heben Sie Quellen, Senken, Transformationsphasen, Klassifizierungen (öffentlich, vertraulich, reguliert) hervor, und legen Sie fest, ob es sich bei der Bewegung um Batch, Streaming oder nahezu in Echtzeit handelt. Sie hilft bei der Analyse von Datenlinien, Governance-Kontrollen und Leistungsengpässen.

Die Modellierung von Sicherheitsrisiken, z. B. das STRIDE-Modell, verwendet ein spezielles DFD. Das Diagramm zeigt Prozesse, Datenspeicher, externe Entitäten, Vertrauensgrenzen und Datenflüsse, die diese Grenzen überschreiten. Der Schwerpunkt liegt auf dem Kommentieren von Flüssen mit Protokollen und Verschlüsselung und hebt Ressourcen hervor, die Schutz erfordern. Diese Abbildung steuert die Validierung der Risikominderung und die Überprüfung der Sicherheitskontrollen.

Sequenzdiagramm

Ein Sequenzdiagramm stellt die zeitliche Anordnung von Interaktionen für einen einzelnen Anwendungsfall oder ein Szenario dar. Der Benutzer platziert z. B. die Reihenfolge. Es veranschaulicht Client-Server-Beziehungen und zeigt deutlich, ob Interaktionen synchron oder asynchron sind. Diese Diagramme heben auch Abhängigkeiten in Kommunikationsmustern hervor und helfen dabei, potenzielle Fehlerszenarien innerhalb von Komponenteninteraktionen auszuwerten. Sequenzdiagramme sind besonders nützlich für das API-Design.

Benutzerfluss- oder Reisediagramm

Ein Benutzerflussdiagramm zeigt End-to-End-Schritte, die ein Benutzer oder persona über Schnittstellen und Dienste hinweg übernimmt. Er visualisiert die Benutzerreise durch das System und zeigt, wie Benutzer und ihre Daten mit verschiedenen Komponenten und Prozessen interagieren. Diese Diagramme sind hilfreich, um funktionale Anforderungen zu klären, das Design der Benutzeroberfläche zu überprüfen und sicherzustellen, dass alle Benutzerszenarien in der Architektur ordnungsgemäß behandelt werden. Anmerkungen zu den Erwartungen auf Leistung oder Servicelevel zu kritischen Flüssen.

Entitätsbeziehungsdiagramm (ERD)

Ein Entitätsbeziehungsdiagramm (ERD) stellt die logische oder physische Datenmodellstruktur dar: Entitäten (Tabellen und Auflistungen), Attribute, Schlüssel und Kardinalitäten. Verwenden Sie logische ERDs für domänenausrichtung und physische ERDs für Implementierungsdetails (Indizes, Partitionierung). Manchmal können hinzugefügte Details wie z. B. Shardingbereiche in diesem Diagramm kommuniziert werden. Diese Diagramme helfen Entwicklern, Datenbeziehungen und Einschränkungen zu verstehen, bevor die Implementierung beginnt.

Diagramm zur Netzwerkkonnektivität

Ein Netzwerkdiagramm veranschaulicht die Arbeitsauslastung aus der Perspektive der Netzwerkinfrastruktur, die zeigt, wo Komponenten über Netzwerkgrenzen hinweg kommunizieren. Diese Diagramme visualisieren die Netzwerksegmentierung, potenzielle Netzwerkfehlerpunkte und kritische Netzwerkübergänge wie Internetausgangs- und Ausgangspunkte. Eine Workload kann von einem Netzwerkdiagramm profitieren, das sich auf den Ost-West-Datenverkehr und ein anderes Netzwerkdiagramm für nord-süd-Datenverkehr konzentriert.

Netzwerkdiagramme verfügen häufig über ein erweitertes Hilfsprogramm über die anfängliche Implementierungsphase hinaus. Sie werden häufig während Sicherheitsprüfungen, Complianceüberprüfungen und Vorfallreaktionsaktivitäten referenziert, wodurch sie wertvolle langfristige Dokumentationsressourcen erhalten.

Zustandsdiagramm

Ein Zustandsdiagramm ist eine spezielle Visualisierung, die mögliche Zustände eines Domänenobjekts, Workflows oder Subsystems anzeigt. Sie enthält die Bedingungen oder Ereignisse, die Übergänge zwischen Zuständen auslösen. So wird beispielsweise beschrieben, wie ein Auftrag vom Entwurf, eingereicht, überprüft, erfüllt und geschlossen wird.

Zustandsdiagramme tragen dazu bei, potenzielle Parallelitätsbedenken, Übergangsbehandlung und ausgleichende Transaktionsanforderungen hervorzuheben. Dies trägt dazu bei, die Wahrscheinlichkeit von unerwarteten Zustandsänderungsverhalten in der Produktion zu verringern.

Flussdiagramm und Aktivitätsdiagramm

Flussdiagramme und Aktivitätsdiagramme bieten Klarheit für komplexe Workflows, Entscheidungslogik und Geschäftsprozesse innerhalb Ihrer Workload. Sie sind nützlich für die Darstellung von Genehmigungsprozessen und Szenarien mit bedingter Verzweigung, die Ihnen dabei helfen, betriebsbereite Runbooks, Automatisierung von Geschäftsprozessen und Vorfallreaktionsflüsse zu dokumentieren.

Andere spezialisierte Diagramme

Typ Wenn es einen eindeutigen Wert hinzufügt Brennpunkt
Verfügbarkeits- und Resilienzzuordnung Überprüfungen der Planung und service level Objective (SLO) während der Notfallwiederherstellung (DR) Redundanz, Failoverpfade, RPO/RTO-Anmerkungen anzeigen.
Compliancedaten-Residency-Karte Regulierte Workloads Datenspeicherort, Replikation, Klassifizierung, Aufbewahrung anzeigen.
Identitäts- und Zugriffsflussdiagramm Sicherheits- und Complianceüberprüfungen Anzeigen von Authentifizierungs- und Autorisierungsflüssen Identifizieren Sie, wo die Tokenausstellung auftritt, wo sich Vertrauensgrenzen ändern und wo Im-Auftrag-von-Flüssen auftreten.

Spezifikationsbasierte Diagrammerstellung

Es gibt mehrere offene Spezifikationen, auf denen Sie Diagramme basieren können. Die Übernahme eines ist eine Arbeitsauslastungsteamentscheidung; Tun Sie dies nur, wenn es erforderliches gemeinsames Vokabular hinzufügt, um Mehrdeutigkeit zu reduzieren. Wenn Ihr aktueller visueller Kommunikationsansatz bereits funktioniert, vermeiden Sie das Hinzufügen von Prozessgewicht nur zur Formalität. Selbst wenn Sie keine Spezifikation übernehmen, können selektiv bewährte Konventionen (Layering, Kardinalitätsnotation, Ereignisbezeichnungen, Legendenmuster) Klarheit und Konsistenz in Ihrem Diagrammsatz auslösen.

Beispiele für Diagramm- und Modellierungsspezifikationen:

Nächste Schritte

Checkliste des Architekten