ISAQB CPSA-F

cpsa-f.md

ISAQB CPSA-F

Certified Professional for Software Architecture Foundation-Level

Eigene Lernziele formulieren

• Software Architekturen bewerten zu können
• Vor- und Nachteile von Architekturentscheidungen zu beurteilen
• Architekturentscheidungen effektiv an Stakeholder zu kommunizieren
• Wechselwirkungen von Architekturentscheidungen
• Querschnittsthemen / Konzepte erkennen


Softwarearchitektur

• � Warum brauchen wir Softwarearchitektur?
  • Um die wesentlichen Ziele unserer maßgeblichen Stakeholder zu erreichen
  • Um Qualitätsanforderungen zu erfüllen (Performance, Skalierbarkeit, Flexibilität, …)
  • Um das System mit angemessenem Aufwand (Personen, technischen Ressourcen) zu entwickeln und betreiben; Time-to-Market
  • Um konzeptionelle Integrität zu gewährleisten (ähnliche Aufgaben werden ähnlich gelöst)
  • Um grundlegende Entscheidungen verständlich zu machen (Komponenten, Schnittstellen, Technologien, Lösungskonzepten)
• � Was gehört zu Softwarearchitektur? Welche Arten von Entscheidungen müssen wir treffen?
  • System (auch: Anwendung, Programm)
    • Gruppe von Elementen, die ein einheitlichen Ganzes bilden / miteinander interagieren
    • Ist in eine Umgebung eingebettet
    • Interagiert mit einem oder mehreren anderen Systemen
    • der Scope definiert, was zum System gehört
  • Komponenten („Baustein“)
    • Bestandteile größerer Einheiten
    • Services, Module, Klassen, Funktionen
    • können auch zugeliefert werden (3rd-Party-Bestandteile, Frameworks, Services)
    • ein System besteht aus mehreren Komponenten
    • Infrastruktur: Server, Container, Firewalls
  • Beziehungen (Abhängigkeiten, Verbindungen, Schnittstellen)
    • Komponenten müssen mit anderen Komponenten interagieren (Separation of Concerns)
    • Entwurf guter Schnittstellen ist schwierig
    • Unterschiedliche Bedürfnisse von Komponenten / Entwicklungsteams
    • Missverständnisse bei Schnittstellen
    • Infrastruktur: Netzwerke, Busse
  • Umgebung („Kontext“)
    • jedes System existiert in einer Umgebung
    • Daten, Events, Kommandos gelangen aus der Umgebung in das System hinein und fließen in die Umgebung zurück
    • externe Schnittstellen (Schnittstellen zur Umgebung)
      • andere IT-Systeme
      • Akteure, interagieren mit dem System
      • Kontextsicht hebt die Bedeutung externer Schnittstellen hervor
    • Strukturen
      • Komponenten + Beziehungen, Umgebung
      • Strukturentscheidungen: Zerlegung des Systems in Komponenten und Beziehungen
      • eine solche Zerlegung erschafft eine innere Ordnung
  • Prinzipien („Konzepte“)
    • querschnittliche Entscheidungen
    • bieten einheitliche Lösungen für wiederholt auftretende Probleme
    • oft wiederverwendbar
    • beinhalten Technologieentscheidungen, Produktentscheidungen, spezifische Vorgehen (Penetrationtest)
    • Qualitätsanforderungen (Performance, Skalierbarkeit, Robustheit) oder Randbedingungen (Budget, gesetzliche Vorgaben) bestimmen oft die Auswahl von Konzepten
  • Architekturentscheidungen
    • basieren u.a. auf
      • funktionalen Anforderungen (was soll das System tun)
      • Qualitätsanforderungen: Performance, Skalierbarkeit, Zuverlässigkeit, Time-to-Market
      • Technologievorgaben
      • Risiken
      • Geld / Zeit
      • gesetztliche Vorgaben
    • Grundregel: Kommt-darauf-an
      • es gibt keine universellen Standardlösungen (silver bullet)
      • in spezifischen Situationen müssen spezifische Entscheidungen getroffen werden
    • Architektur benötigt (oft) Kompromisse zwischen widersprüchlichen / konkurrierenden Anforderungen
    • „latest responsible moment“ (LRM) für Wahl des Entscheidungszeitpunkts finden, vor der Entscheidung so viel wie möglich über die Fragestellung lernen
    • Kategorien
      • Strukturen entwerfen
      • Konzepte entwerfen
      • Make-or-Buy
• � Welche Aufgaben muss Softwarearchitektur lösen?
  • Anforderungen klären
  • Make-or-buy
  • Strukturen entwerfen (Komponenten und Schnittstellen)
  • Konzepte entwerfen (Technologie, Prinzipien, Regeln, Patterns)
  • Architektur kommunizieren dokumentieren
  • Umsetzung begleiten
  • Architektur analysieren / bewerten (Systematische Bestandsaufnahme, was läuft gut, Risiken, Probleme)
  • Ständig lernen (Trends, Technologien, Methodiken)
• � Wer könnte diese Aufgaben übernehmen (Rolle von Softwarearchitekt:innen)?
  • zentralisiert vs. Dezentralisiert
  • Monarchie
    • eine einzelne Person macht Vorgaben zur Architektur
    • Vorteile:
      • schnelle, konsistente Entscheidungen
      • erfahrener Architekt kann unerfahrenes Team coachen
      • einzelner Ansprechpartner
    • Nachteile:
      • Engpass hinsichtlich Zeit und Verfügbarkeit (Bus-Faktor 1)
      • suboptimale Entscheidungen bei fehlendem Know-how
      • fehlendes Feedback, falsche Entscheidungen werden sehr spät gefunden
    • Wann?
      • Outsourcing
      • Coaching
      • Entwicklung mit hohem Zeitdruck (kleines / mittleres System)
      • Standardaufgaben
  • Architekt im Team
    • befähigt das Team, eigene Entscheidungen zu treffen
    • keine absolute Entscheidungsgewalt (nur in Zweifelsfällen)
    • Vorteile:
      • einzelner Anspruchpartner
      • konsistente Enscheidungen
      • Teams können Feedback geben
    • Nachteile:
      • Bus-Faktor 1
    • Wann?
      • kleines Team
      • hoher Coachingbedarf
      • erfahrener Architekt mit Know-How in eingesetzter Technologie (und Fachdomäne)
      • klar definierte Rollenmodelle
  • Architekturagenten
    • Mehrere Personen (optimal: 3) teilen die Architekturarbeit untereinander auf (z.B. nach Thema oder Tätigkeiten)
    • Vorteile:
      • schnelles Feedback
      • mehrere Ansprechpartner / Coaches
      • Vergemeinschaftung von Architekturwissen (Bus-Faktor > 1)
      • hohe Akzeptanz im Team (rotierende Agentenrolle)
    • Nachteile:
      • Organisationsaufwand bei Besetzung der Architekturagenten
      • Organisationsaufwand bei Etablierung der Kommunikationsprozesse
      • erhöhter Abstimmungsaufwand
    • Wann?
      • Aufgaben eines Projekts zu groß / schwierig
      • Architekturfähigkeiten können im Team etabliert werden (rollierender Beteiligter)
      • „Geteiltes Leid, halbes Leid“
  • Team-Architektur
    • das gesamte Team stimmt sich zu Architekturfragen ab
    • Vorteile:
      • hohe Akzeptanz
      • die Erfahrung aller Personen fließt ein
    • Nachteile:
      • Junktim-Entscheidungen
      • Konsistenz geht verloren
      • Diskussionen / Entscheidungen können lange dauern
    • Wann:
      • kleine Teams (7-8 Personen)
      • homogenes Know-how
      • gegenseitige Akzeptanz

Anforderungen klären

• Was ist die Kernaufgabe des Systems?
  • 2-3 Sätze, positive Formulierung
  • enthält wichtigsten Begriffe der Fachdomäne (5-10) hinzu
  • dient zur Orientierung
• Relevante Stakeholder ermitteln
  • Welche Rollen / Personen haben Interesse am System (intern / extern)
  • Welche Erwartungshaltung haben die Stakeholder gegenüber Architektur- und Entwicklungsteam (Artefakte, Dokumente)
• Fachdomäne klären
  • umfasst Prozesse, Aktivitäten, Regeln und Daten eines Anwendungsbereichs
    • DDD
      • mit Fachleuten und dem Entwicklungsteam wesentlichen Begriffe aus der Domäne sammeln und deren Bedeutung definieren („Ubiquitous Language“)
      • wesentliche Abläufe innerhalb der Domäne klären (Event Storming, Domain Story Telling)
      • „Events“ um notwendige Daten und Informationen anreichern
    • Requirements Engineering (klassische Anforderungsanalyse)
      • Funktionale Anforderung auf unterschiedlichen Verfeinerungsebenen betrachten
        • Geschäftsprozesse
        • Aktivitäten
        • Stories / Features
• Qualitätsanforderungen klären
  • die Qualität von Produkten setzt sich aus vielen Eigenschaften zusammen (es gibt kein absolutes Maß!)
    • Performanz
    • Verfügbarkeit
    • Änderbarkeit
  • für verschiedene Stakeholder sind oft unterschiedliche Eigenschaften relevant, z.B.
    • Management: Time-to-Market
    • Endanwender: Benutzbarkeit
    • Ops: Robustheit
  • Qualitätsanforderungen müssen explizite Entwurfsziele sein!
  • Qualitätsmodelle liefern Vorschläge für Qualitätsanforderungen, diese sind aber beliebig interpretierbar (z.B. Flexibilität)
  • Qualitätsszenarien konkretisieren Ausprägungen der Qualitätsanforderungen (z.B. die Unterstützung einer neuen Browserversion innerhalb von 3 Personentagen)
    • Ereignisse werden von Stakeholdern / Systemen ausgelöst (z.B. Funktionsaufruf)
    • eine Antwort/Reaktion beschreibt, wie das System auf das Ereignis reagiert (z.B. wird die Funktion ausgeführt)
    • Metrik beschreibst einen Messwert dieser Antwort (z.B. Reaktionszeit in s)
• Externe Nachbarsysteme: Kontextabgrenzung
  • welche Schnittstellen gibt es zu externen Systemen
    • Schnittstellen anderer genutzter Systeme
    • Schnittstellen für andere Systeme
  • sind stabil ist die externe Schnittstelle externer Systeme
  • wie fehlertolerant muss das neue System gegenüber externen Systemen sein
  • wie performant sind die anderen Systeme
  • kann die externe Schnittstelle externer Systeme geändert werden
  • dokumentieren sie das System als Diagramm
  • erläutern sie das Diagramm mit einer Tabelle (Bezeichnungen der Schnittstellen, required vs. provided, fachliche Bedeutung)
• Einflussfaktoren und Randbedingungen ermitteln
  • Organisatorische und politische Faktoren
    • Beziehen sich im weitesten Sinne auf die Umgebung, in der das System erstellt wird
    • Beispiele:
      • Termin- und Budgetplanung
      • vorhandene Mitarbeiter
      • Entwicklungsprozesse
    • Identifikation von organisatorischen Faktoren und Risiken
      • Denken sie negativ!
      • Politik und Organisation setzen die Grenzen dafür was Entwicklungsteams erreichen können
      • Geld = Politik
      • Welche Ziele verfolgen einzelne Stakeholder mit dem System
      • Die Erfahrung der beteiligten Entscheider spielt eine Rolle (z.B. negative Erfahrung mit Technologie X)
      • Werfen Sie einen Blick auf die Riskoliste ihres Managements
  • Technische Faktoren
    • Beispiele
      • technische Infrastruktur
      • technische Vorgaben
      • Fremdsoftware
      • Vorhandene Systeme
    • Identifikation von technischen Faktoren
      • andere Systeme innerhalb der Organisation betrachten
      • wie sieht deren Umgebung und deren Betrieb aus
      • vorhanderen Infrastruktur und Software betrachten (OS, Datenbanken, Frameworks, Bibliotheken)
  • Es gibt keine rein technischen Probleme!

Grundlagen, Prinzipien und Heuristik

• Grundlagen = allgemeingültige Regeln, abstrakt
  • Stakeholder beurteilen Erfolge von Lösungen (Business Drives Technology)
    • Stakeholder haben kurz- und langfristige Interessen (z.B. Wartbarkeit, Verständlichkeit)
  • Einfachheit gewinnt (KISS, Wie geht das einfacher?)
    • erleichtert das Verständnis
    • vermeidet potentielle Probleme durch überflüssige Komplexität (accidental complexity)
    • leichtere Wartung und Implementierung
  • Entscheiden Sie spezifisch (No silver bullet)
    • kein Patentrezept für beliebige Entwurfsprobleme
    • Notwendigkeit system-spezifischer Entscheidungen, um eine angemessene Lösung für ihre Anforderungen zu erarbeiten (it depends)
  • Besser explizite Aussagen statt impliziter Aussagen
    • Vorraussetzungen / Annahmen / Entscheidungen explizit machen, um unterschiedliche Interpretationen durch implizite Annahmen) zu vermeiden
    • Beispiele expliziter Aussagen:
      • Domänenmodell
      • klar benannte Verantwortlichkeiten von Bausteinen
      • ausdrücklich formulierte Qualitätsanforderungen
  • Erwartete Änderungen
    • mit der Zeit verändern sich Lösungen / Probleme / Technologien / Organisationen usw.
    • richten sie sich bei ihren Entwürfen auf Veränderung ein
    • agile Entwicklungsmethoden (z.B. Scrum) berücksichtigen diese Änderungen durch Iterationen und systematisches Feedback
    • Änderbarkeit kann leicht übertrieben werden
      • hochgradig konfigurierbare Systeme sind schwerer zu testen und weniger robust
  • Erwarte Fehler
    • stellen sie sich auf Fehler / Ausfälle / Defekte ein
    • stellen sie immer Fragen der Form
      • Was könnte ausfallen?
      • Was könnte anders sein als abgesprochen?
    • sorgen sie dafür, dass Fehler leicht gefunden werden können (Einfachheit)
    • halten sie Auswirkungen von Fehlern lokal (keine Störung des Gesamtsystems)
• Prinzipien = konkrete und etablierte Regeln des methodischen Software-Engineering
  • Wäge Prinzipien gegen Anforderungen ab
  • Lose Kopplung
    • Kopplung = Abhängigkeit zwischen Bausteinen
      • ermöglicht die Zusammenarbeit von Bausteinen
      • Änderungen an einem Baustein führen zu Konsequenzen an anderen Stellen
    • lose Kopplung
      • fördert Einfachheit, Voraussetzung für Flexibilität und Änderbarkeit von Entwürfen
    • hohe Kopplung
      • erschwert Verständlichkeit, führt zu Starrheit von Entwürfen
    • statische Kopplung
      • Abhängigkeiten zur Compile-Zeit
      • z.B. Codeabhängigkeiten, Importe von anderen Bausteinen, Frameworks usw.
      • einfach zu verstehen, Abhängigkeiten klar definiert
      • eine zu starke statische Kopplung schränkt Änderbarkeit / Wiederverwendbarkeit / Testbarkeit ein
    • dynamische Kopplung
      • Abhängigkeiten zur Laufzeit
      • z.B. Dependency Injection, Kommunikation über Message Queues
      • erhöht Flexibilität und Erweiterbarkeit
      • erschwert Verständlichkeit, weil Abhängigkeiten im Quellcode oft nicht sichtbar sind
    • afferente und efferente Kopplung
      • efferente Kopplung misst die Anzahl der ausgehenden Abhängigkeiten
        • hohe Werte deuten auf schlechte Wiederverwendbarkeit und eingeschränkte Verständlichkeit hin
      • afferente Kopplung misst die Anzahl der eingehenden Abhängigkeiten
        • hohe Werte deuten auf eine kritische Rolle im System hin
    • Hohe Kohäsion
      • wie eng hängen Bausteine inhaltlich zusammen
      • jeder Baustein sollte eine hohe Kohäsion besitzen
      • unklare Definition, was inhaltlich zusammengehört
      • erfordert explizite Kriterien
    • Trenne Verarntwortlichkeiten (Separation of Concern)
      • geben sie Bausteinen verschiedene Verantwortlichkeiten
      • nennen und beschrieben sie diese in kurzen, präzisen Sätzen
      • mehrere „und“ = Vermischung mehrerer Verantwortlichkeiten
      • Verantwortlichkeiten für
        • Wissen (Informationen)
        • Handeln (Aktivitäten)
      • Auswirklungen auf Kopplung und Kohäsion
      • Ausprägungen:
        • Systeme in fachliche und technische Bestandteile teilen
        • Schreibende und lesende Bausteine trennen
    • Modularisierung
      • besagt, ob und wie ein System in eine Menge in sich geschlossener Bausteine zerlegt wurde
      • Module sollten Blackboxes sein, es genügt die Schnittstelle zu kennen
      • Module können
        • getrennt voneinander entwickelt werden
        • unabhängig voneinander geändert werden
        • durch Bausteine mit identischer Schnittstelle ausgetauscht werden
    • Abstraktion, Kapselung und das Geheimnisprinzip (Information Hiding)
      • trennen sie das „Was“ (Schnittstelle) vom „Wie“ (Implementierung)
      • bei Missachtung entstehend ungewollte und schwierige Abhängigkeiten (was bekannt ist, wird auch genutzt)
    • Hohe Konsistenz
      • konzeptionelle Integrität ist eine wesentliche Eigenschaft guter Entwürfe
      • ähnliche Probleme sollten ähnlich gelöst werden
      • steigert Verständlichkeit von Systemen
    • Keine zyklischen Abhängigkeiten
      • erschweren Wartbarkeit und Änderbarkeit von Systemen
      • können nicht immer vermieden werden
    • SOLID Prinzipien
      • Single Responsibility Principle
        • eine Klasse sollte nur genau einen Grund haben, geändert zu werden
      • Open-Close Principle
        • Komponenten können erweitert werden, ohne bestehenden Code zu modifizieren
        • Änderungen wirken sich nicht auf bestehenden Code aus
        • entkoppelt die Schnittstelle von der Implementierung
        • Beispiel: Form Interface mit draw() Funktion
      • Liskov Substitution Principle
        • Unterklassen müssen grundsätzlich für ihre Oberklassen ersetzt werden können
      • Interface Segregation Principle
        • mehrere spezifische Schnittstellen sind oftmals besser als eine große Universalschnittstelle
        • hält Schnittstellen einfacher und verständlicher
        • Änderungen an einer Schnittstelle zieht keine Änderungen an anderen Schnittstellen nach sich
        • das System ist dadurch flexibler und wartungsärmer
      • Dependency Inversion Principle
        • erlauben sie Abhängigkeiten nur von Abstraktionen, nicht von konkreten Implementierungen
        • steigert Flexibilität und Erweiterbarkeit (Implementierungen können ausgetauscht werden)
• Heuristiken = die Kunst (nicht Prozess), mit unvollständigen Informationen zu angemessenen Lösungen zu kommen
  • Regeln zur Behandlung komplexer und wenig strukturierter Probleme (geben Orientierung, keine Garantie)
  • Recherchiere gründlich
    • lernen sie aus unterschiedlichen Quellen möglichst viel über das Problem
    • erarbeiten sie die Grundbegriffe des Problemraums und deren Zusammenhänge
    • beantworten sie die Fragen
      • Gibt es Beispiele für erfolgreiche Lösungen?
      • Gibt es Beispiele für gescheiterte Lösungen?
      • Wer kann ihnen helfen?
  • Verfeinere schrittweise
    • zerlege Probleme in immer kleinere Teile, bis diese Teilprobleme überschaubar sind (divide and conquer)
  • Trial-and-Error
    • Ausprobieren hilft, mehr über ein komplexes Thema zu lernen (Prototypen, Pilotprojekte, Testen)
    • wichtig sind dabei Bewertung und Feedback
    • Testen Sie so früh wie möglich
  • Generalisiere
    • suchen sie nach Dingen, die sie anhand gemeinsamer Kriterien zusammenfassen können
    • Beispiele:
      • Zusammenfassung externer Schnittstellen anhand fachlicher Inhalte (z.B. System zur Kreditkartenprüfung)
      • Generalisierung ähnlich aufgebauter Abläufe (z.B. CRM-System)
      • Vererbungshierarchien
  • Spezialisiere
    • betrachten sie Spezialfälle, um wiederkehrende Lösungsmuster / typische Probleme zu erkennen
    • Beispiele:
      • „Sonnenschein“-Fall (alles läuft gut)
      • Können sie diesen Fall vereinfachen (triviale Spezialisierung)
      • unkritisches Fehlerszenario
      • Worst-Case-Szenario
  • Wechseln Sie die Perspektive
    • versetzen sie sich in andere Personen
    • dadurch können sie die Konsequenzen ihrer Entscheidungen besser einschätzen
    • Beispiele:
      • Architektursichten
      • Kontextabgrenzung (System als Blackbox)
      • Fachdomäne
      • Laufzeitverhalten
  • Achte auf Schnittstellen
    • Bausteine kommunizieren über Schnittstellen miteinander
    • über Schnittstellen findet die Kommunikation mit der Außenwelt statt
    • Fehler an Schnittstellen betreffen immer mindestens zwei Bausteine
  • Kenne die Risiken
    • beginne mit den einfachen Teilen eines Systems
      • das Team gewinnt Vertrauen und Feedback der Stakeholder
      • die schwierigen Aufgaben hat das Team noch vor sich (Risiken und Unwägbarkeiten)
    • beginne mit den schwierigen / riskanten Teilen eines Systems
      • Normalfall für Entwicklungsteams
      • große Probleme können früh identifiziert werden
      • es dauert länger, bis sie „vorzeigbare“ Resultate zeigen können
    • klären mit dem Entwicklungsteam, wo Schwierigkeiten / Probleme lauern
    • legen sie Risiken offen
  • Beachte die Geselligkeit von Fehlern
    • nicht entdeckte Fehler in einem Baustein sind proportional zur Anzahl der bereits entdeckten Fehlern (Fehler clustern)
    • Indikator für erhöhte Komplexität - Bausteine vereinfachen

Schichten (Layer)

• Mittel zur Strukturierung
• eine Schicht bietet der darüberliegende Schicht Dienste an (services)
• nur obere Schichten dürfen Dienste unterer Schichten nutzen
• Vorteile:
  • die Implementierung einer Schicht kann ausgetauscht werden
  • Abhängigkeiten zwischen Komponenten verschiedener Schichten kann reduziert werden
  • leicht verständlich
• Nachteile:
  • kann Performance beeinträchtigen
  • Layer-Bridging verbessert die Performance, führt aber zu neuen Abhängigkeiten
  • mache Änderungen (Datenmodell) führen zu Änderungen in allen beteiligten Schichten
• Vorschlag für Schichten
  • Präsentation (Benutzeroberfläche)
  • Fachdomäne (fachliche Aspekten)
  • Infrastruktur
    • kann bei Bedarf weiter untergliedert werden (z.B. Integrationsschicht, Ressourcenschicht)
  • Nachteile der (Standard-Schichten)
    • fachliche Logik infiltriert häufig Applikations- und Prösentationsschicht
      • Testbarkeit der Fachlichkeit sinkt
      • alternative Nutzung z.B. über Batch Schnittstelle wir erschwert
      • Verständlichkeit des Gesamtsystems sinkt (niedrige Kohäsion)
    • es dringen leicht technische Details über die Persistenz die Fachdomäne

Microservices

• Aufteilung größerer Systeme in einzeln entwickel-, deploy- und betreibbare Einheiten
  • Erhöht Flexibilität
  • Schnellere Entwicklung durch kleinere Einheiten
  • unabhängige Technologieentscheidungen
  • eigene Ablaufumgebung
  • Kombinieren Konzepte wie Continuous Delivery mit Softwarearchitektur, Betrieb und Teamstruktur
• Eigenschaften:
  • Modularisierung anhand von fachlichen Funktionen und Services
  • eigene Ablaufumgebung, Deployment und Skalierung
  • unabhängige Teams verantworten einen oder mehrere Services
  • verwalten ihre eigenen Daten (polyglot persistence)
  • die Infrastruktur ist automatisiert
  • Kommunikation zwischen Services findet „remote“ statt (z.B. über HTTP)
• Microservices und Organisation
  • cross-funktionale Teams kümmern sich von Konzeption bis Produktion um „ihr Produkt“ (You build it, you run it)
  • jedes Team besitz Expertise in allen Arbeitsbereichen
• Für welche Systeme eignen sich Microservices?
  • Anwendungen, bei denen fachliche Funktionalitäten voneinander getrennt entwickelt und betrieben werden können
  • Anwendungen, bei denen einzelne Teile getrennt skaliert werden müssen
• Für welche nicht?
  • keine Automatisierung von Build/Deploy/Release möglich
  • Entwicklung und Betrieb strikt voneinander getrennt
  • Betrieb besteht auf vierteljährliche / längere Release-Zyklen
• Herausforderungen:
  • grundlegende Probleme müssen jedes Mal neu gelöst werden (Entwickeln, Testen, Bauen, Deployen)
  • konsistente Benutzeroberfläche
  • Konsistenz von Daten
  • Verwaltung vieler Laufzeitumgebungen (aufsetzen, betreiben, überwachen)
• Überblick über viele Services behalten
  • Einheitliche Dokumentation von APIs (z.B. Swagger)
  • Vorgaben, wie Services miteinander kommunizieren
  • Automatisierung und Standardisierung von Monitoring und Logging
• Microservices effektiv entwickeln
  • verwenden sie eine Schablone / Archtetyp der querschnittliche Themen wie Monitoring, Deployment usw.
• Service Discovery
  • ein Service möchte den Dienst eines anderen Services nutzen
  • Client-Side Discovery:
    • der Consumer fragt eine Service-Registry nach einer Instanz und schickt den Request dorthin
  • Server-Side Discovery:
    • der Consumer sendet die Anfrage an einen Router
    • Der Router fragt die Service-Registry nach einer Instanz und leitet den Request weiter
• UI-Integration
  • jeder Microservice bringt seine eigene UI mit
  • jeder Microservice stellt eigene UI Anteile bereit
  • eine gemeinsame Benutzeroberfläche nutzt andere Microservices über deren Schnittstelle (Frontend-Monolith)
• Dezentralisierte Datenhaltung
  • jeder Microservice hält seine eigenen Daten
  • Datenänderungen über mehrere Systeme werden über Event-Mechanismus verteilt
  • zeitlich verzögerte Datenkonsitenz (eventual consistency)
• Laufzeitumgebung / Infrastruktur verwalten
  • Automatisierung von Laufzeitumgebung und Infrastruktur (Cloud- und Container-Technologie)

Pipes und Filter

• eine Folge von Verarbeitungseinheiten (Filter), verbunden durch Datenkanäle (Pipes)
• Filter erhalten Daten über Eingangs-Pipe(s) (Source), verarbeiten sie und geben sie über die Ausgangs-Pipe(s) (Sink) weiter
• Verzweigungen über mehrere Ausgangspipes möglich
• aktive Filter (pull und push)
• passive Filter
• Pipes können Daten Puffern, und unterschiedliche Verarbeitungsgeschwindigkeiten ihrer Ein-/Ausgangsfilter auszugleichen
• Kriterien für die Anwendung:
  • Ergebnisse können durch eine Kette von Verarbeitungsschritten entstehen
  • datensätze können unabhängig voneinander verarbeitet werden
  • das Datenformat ist stabil
• Vorteile:
  • einfache Struktur
  • lose Kopplung
• Nachteile:
  • Fehlerbehandlung (Folgefehler)
  • Konfiguration der gesamten Verarbeitungskette
  • kein gemeinsamer Zustand, alle Verarbeitungsinformationen müssen übertragen werden
• Implementierung
  • in der Praxis häufig Kombinationen aus batch-sequenziell Pipes und Filter

Dependency Injection

• bei Nutzung von Schnittstellen besteht das Problem, zu einer (abstrakten) Schnittstelle zur Laufzeit eine (konkrete) Instanz zu beschaffen
• Dependency Injection stellt dafür einen eigenständigen Baustein zur Verfügung (Assembler)
• der Assembler erzeugt konkrete Instanzen und übergibt die Referenzen an abhängige Objekte

Typische Architektursichten

• Architektur kommunizieren und dokumentieren
  • Warum kommunizieren und dokumentieren?
    • um ein gemeinsames Verständnis sicherzustellen
    • um Entscheidungen zu herbeizuführen
    • um Feedback zu ermöglichen
  • Wie erfolgt die Kommunikation?
    • mündlich (gemeinsames Erarbeiten, Vorstellen, Überzeugen)
    • schriftlich (Dokumente, Modelle)
      • methodisch, strukturell fundiert, sparsam
  • Modelle
    • vereinfachte Darstellungen der Realität
    • helfen, bestimmte Details der Realität auszublenden
    • Typen:
      • Modelle fachlicher Situationen (Prozess- oder Ablaufmodelle, Datenmodelle)
      • Modelle von Codestrukturen (Komponenten- oder Klassendiagramm, Ablaufdiagramm)
      • Modelle größerer Zusammenhänge (Komponenten-, Kontext-, Verteilungsdiagramme)
    • „Kästchen und Pfeile“
  • Dokumentation für verschiedene Stakeholder
    • stimmen sie den Kommunikations- und Dokumentationsbedarf mit ihren Stakeholdern ab
      • fragen sie Stakeholder im Vorfeld nach deren Bedürfnissen und Vorstellungen von Dokumentation und Erläuterungen
      • holen sie aktiv Rückmeldung von ihren Stakeholdern ein
      • bleiben sie offen für Verbesserungsvorschläge, aber zeigen sie bei Bedarf Durchsetzungsvermögen
• Bestandteile von Architekturdokumentation
  • Kontextabgrenzung (Vogelperspektive)
    • zeigt das Umfeld eines Systems
    • zeigt das gesamte System als Blackbox
    • zeigt Schnittstellen zu Systemen der Außenwelt inkl. der transportierten Daten
    • zeigt Schnittstellen zu Anwendern und Fremdsystemen
    • kann die Vogelperspektive aus rein fachlicher Sicht (fachlicher Kontext)
    • kann die relevanten Elemente der technischen Infrastruktur (technischer Kontext) zeigen
    • zeigen sie in jedem Fall sämtliche Nachbarsysteme inklusive ein- und ausgehender Daten und Ereignisse
    • bietet Grundlage zur Kommunikation mit anderen Stakeholdern über System und externe Nachbarn
      • fragen sie nach Risiken an den externen Schnittstellen oder nach fehlenden Inputs/Outputs
    • Notation
      • C4 oder UML-Komponentendiagramme
  • Bausteinsicht (Code-im-Großen)
    •