Softwaretechnik
Lesson 7
Architektur Patterns und Dokumentation
Pattern
Muster wie wiederkehrende Probleme gelöst werden können
Abhängigkeitsmuster
Dreischicht Architektur
Variante 1
- Client (z.B. Browser)
- Applikationsserver
- Datenbank
Variante 2
Innerhalb eines Applikationsservers (oder Clusters)
- UI
- Domänenlogik
- Persistenz
Wie sehen hier die statischen Abhängigkeiten aus?
Naive Variante
UI
- hängt ab von ->
Domain Logic
- hängt ab von ->
Persistence
Problem
Welche von den Komponenten ist die stabilste?
Domänen Logik
Stabile Komponenten sollten nicht von Instabilen abhängen, da sich die Instabilität sonst übertragen kann.
Hexagonale Architektur
UI --> Domain Logic
Persistence --> Domain Logic
Schnittstelle --> Domain Logic
Transaktionsmuster
ACID
Atomar
Consistence
Isolation
Durability
Isolation in der Realität nur eingeschränkt gegeben
Verarbeitung einer Aktion
User Aktion
-> Abarbeiten der Domain Logik
-> persistentes speichern der Daten (gegebenenfalls inklusive verfügbar machen über mehrere Knoten)
-> Feedback an den User.
Problem
Performance und Skalierbarkeit
Persistent speichern ist langsam
Eventual Consistent
User Aktion
-> erzeugen eines Events in Domain Logik Queue
-> User kann weiter arbeiten
Event in Domain Logik Queue
-> abarbeiten der Domain Logik
-> Event in Persistenz Queue
Event in Persistenz Queue
-> speichern
-> Erfolgs Event in User Queue
In Problemfällen: jederzeit ein Event in die User Queue
Vorteile
Parallelisierbar
dadurch skalierbar
weniger Wartezeiten für den User
Nachteile
komplexere Szenarien müssen durchdacht werden,
da Events auch in Situationen kommen zu denen sie eigentlich keinen Sinn machen.
Interaktion zwischen
Client und Server
RPC (Remote Procedure Call)
-
Es wird eine Schnittstelle spezifisch für die Anwendung entworfen.
-
Der Server implementiert diese Schnittstelle.
-
Der Client benutzt die Schnittstelle.
-
Clientseitig wird ein Stub deployed der Aufrufe über eine Transportprotokoll an der Server übermittelt.
-
Zustand der Anwendung wird auf dem Client und dem Server gehalten.
Problem
Infrastruktur kann mit der Kommunikation nichts anfangen. (kein Proxy, kein Single Sign On, kein Caching)
Client muss den Server sehr genau kennen. (Keine Suchmaschinen)
Client und Server können nicht einfach gewechselt werden. (Scalability, Availability)
REST (Representational State Transfer)
-
Der Server bietet identifizierbare Ressourcen (Web: URLs)
-
Auf jeder Ressource können die gleichen Aktionen durchgeführt werden
-
Diese Aktionen sichern gewisse Dinge zu
-
Als Resourcen wird Hypertext verwendet
-
Der Client enthält keinen Zustand
HTTP Verben
- GET: Keine Seiteneffekte (nullipotent)
- PUT, PATCH, DELETE: Idempotent (erste Durchführung einer Aktion hat einen Seiteneffekt, eine Wiederholung hat keinen weiteren Effekt)
-
POST: Seiteneffekt behaftet.
Hypertext (HTML)
Links machen weitere Resourcen entdeckbar
Vorteile
-
Eine Anwendung muss nur eine Start URL kennen.
-
Durch die Garantien der Verben kann Infrastruktur implementiert werden, die dies ausnutzt:
-
Caches, Load Balancing und dergleichen mehr
Architektur Dokumentation
Aufgabe: Hexagonale Architektur
Implementieren sie das CreateCD Beispiel wie in der Vorlesung skizziert
Mindestens die ersten 5, die ihren Source Code auf Github allgemein verfügbar machen, werden gereviewed.
Verfügbar machen bedeutet:
- Als Wiki Artikel im Repository zur Vorlesung
- Oder als eigenes Repository
Aufgabe: Arc42 Template durcharbeiten
Sie sollten in der Lage sein Fragen der Art:
"Was wird in Abschnitt XYZ dokumentiert?"
beantworten können.
Weiterführende Literatur
Effektive Softwarearchitekturen: Ein praktischer Leitfaden (Starke)
Softwarearchitekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten (Zörner)
Softwaretechnik Lesson 7
By Jens Schauder
Softwaretechnik Lesson 7
- 1,492
