SWT2

Implementierung

Externe Dienste

Ausführungsumgebung

Benutzerverhalten

Service Effekt Spezifikation

beschreibt das Verhalten einer Komponente

zusammengesetzt aus Services

Organisiert um die Business Capabilities

Produkte nicht Projekte → Enduser taugliche Funktionalität → Teams sind auch für das Deployment zuständig DevOps

Smarte Enpoints and Dumb Pipes → service soweit wie möglich entkoppeln und möglichst hohe Kohäsion → REST bekomme eine anfrage verarbeite diese und gebe eine Antwort

Dezentralisierte Verwaltung → Idee des Produzieren eines Tools das anderen Developer benutzen könne um einfache Probleme zu lösen

Dezentralisiertes Datenmanagement → nicht unbedingt gleiches DB Schema → meistens jeder managet seine eigene DB

Automatisierte Infrastruktur → automatisiertes build und deploy → CI/CD Pipeline

Design for failure → wenn ein einzelner microservice nicht mehr funktioniert sollten die anderen noch funktionieren

Evolutionäres Design

Stateless → dadurch Skalierbar

Skalierbarkeit

Self-Service

Ubiquitärer Netzwerkzugriff

Ressource Pooling

Measured Service

Dezentralisierung: um bottlenecks und single point of failure zu vermeiden

Asynchron: Das System macht unter allen Umständen Fortschritte

Eigenständigkeit: Das System ist so entwickelt, das individuelle Komponenten ihre eigenen Entscheidungen treffen können basierend auf den lokalen Infos

Lokale Verantwortung: Jede Komponente ist selbst für ihre Konsistenz verantwortlich

kontrollierte Nebenläufigkeit: Operationen erfordern keine oder limitierte Nebenläufigkeitskontrolle

Fehlertolerant: Das System geht mit Fehlern von anderen Komponenten normal um ohne Unterbrechung

Kontrollierte Parallelität : Granularität des Systems muss so grob sein, dass Parallelität genutzt werden kann um die Performance zu steigern

Kleine Building Blocks

Symmetrie: homogene Systeme : alle Knoten benötigen ähnliche Funktionalität (keine Spezialserver etc.)

Einfachheit: Das System sollte so einfach wie möglich sein

Versichere dich das deine Anwendung skalierbar ist → indem du jede Komponente skalierbar entwirfst

Versichere dich das deine Komponenten lose gekoppelt sind → asynchrone Kommunikation

Implementiere Parallelität für bessere Nutzung der Infrastruktur und Performance

Sorge für Widerstandsfähigkeit des Systems → asynchrone Kommunikation

Vergiss die Kosten nicht → benutze on Demand Ressourcen

Image Manifest

• indiziert Schema version

• referenziert alle Konfigurationen

File System Layers

• spezifiziert das archivieren des Containerinhalts

Image Index

• deklariert Plattform Anforderungen und beinhaltet manifests

Container Configuration

• beschreibt das deployment eines Containers

Core Domain

• wichtiger Aspekt eines Domänen Models um ein Domänen spezifisches Problem zu lösen

• Alle anderen unterstützen die Core Domain

Shared Kernel

• Domänen Konzept welches zwischen versch. Domänen geteilt wird

• gewartet und entwickelt von mehreren Teams

• Aufwand für Koordination und Integration

Supporting Domain

• umfasst Konzepte, die aus dem Kernbereich extrahiert wurden

• Konzepte aus dem Kernbereich, die eine unterstützende Rolle für den Kernbereich spielen

Generische Subdomain

• kapselt generische Konzepte die nicht zur Core Domain gehören

• kann ausgelagert oder durch Standardkomponenten ersetzt werden

Inspektion

Team Review

Walkthrough

Pair Programming

Pass-around

entwickle software iterativ

manage Anforderungen

benutze Komponentenbasierte Architekturen

modelliere die Software sichtbar

verifiziere Softwarequalität

kontrolliere Änderungen an der Software

Vorteile

• schnelles Feedback von Kunden über Produktqualität

• Disziplinierter Prozess

• übergibt Verantwortung an alle Teammitglieder

• agile Projekte gehen nicht von einer stabilen Welt aus

Nachteile

• Unklar wie man Architekturdesign in agile Projekte einbringt

• Unklar wie es mit großen Projekten skaliert

• Druck für manche Mitglieder wegen Verantwortung

EBP ist definiert als

• eine Aufgabe

• ausgeführt von einer Person

• in einem Ort zu einer bestimmten Zeit

• als Antwort auf ein Business Event

• welches messbares Businesswert hinzufügt

• und die Daten in einem konsistenten Zustand hinterlässt

häufiges Problem: Use Cases zu low level

Protected Single Channel Pattern

Monitor-Actuator Pattern

Sanity Check Pattern

Watchdog Pattern

Safety Executive Pattern