AALM

Beschreibt Beziehungen und Kommunikation zwischen den Modellen.

Shared Kernel – Geteilte Inhalte eines Modells. Sollten möglichst klein gehalten werden.

Customer/Supplier Development – Klare Kunden/Lieferantenbeziehung. Nachgelagerte Prioritäten fliessen in vorgelagerte Planung ein.

Conformist – Halten sich strikt an das vorgelagerte Modell. Beseitigt Komplexität.

Anticorruption Layer – Isolationsschicht, welches gewisse Funktionalitäten des vorgelagerten Systems in Bezug auf das eigene Domänenmodell zur Verfügung stellt.

Open-host Service – Definiert Protokoll das Zugriff auf Subsystem als Reihe von Diensten erlaubt.

Separate Ways – Keine Beziehungen zu anderen Bounded Context.

• Architektur- und Organisationsansatz in der Softwareentwicklung
• Kleine unabhängige Services, welche über API miteinander kommunizieren
• Service durch kleine, eigenständige Teams

Funktion einer Applikation können ein- und ausgeschaltet werden. Neue Funktionen im Trunk. Branching und Merging entfallen – Reduziert Fehleranfälligkeit.

Logische Darstellung einer wiederholbaren Geschäftsaktivität, die ein bestimmtes Ergebnis hat (z. B. Überprüfung der Kreditwürdigkeit eines Kunden).

Datenbanken separieren

Code auf gleicher Maturitätsstufe

Separate Builds pro Service

Zentrale Verantwortlichkeit

In Container deployen

Server als Stateless behandeln

Domain-Driven Design

Micro Frontends 

Orchestrieren der Mikroservices.

1. Zielarchitektur definieren, Bounded Context definieren, Sprache festlegen, Infrastruktur von Geschäftscode trennen.

2. Existierenden Code in neues Subsystem verschieben

3. Verteilen der Subsysteme.

Der Bounded Context definiert den Einsatzbereich eines Domänenmodells. Es umfasst die Geschäftslogik für eine bestimmte Fachlichkeit. Als Beispiel beschreibt ein Domänenmodell die Buchung von S-Bahn-Fahrkarten und ein weiteres die Suche nach S-Bahn-Verbindungen

Automatisiert Auslieferung von Software, ist reproduzierbar, birgt geringes Risiko für neue Versionen.

Prozess wie Code erstellt, getestet und auf verschiedene Systeme deployt wird. Produziert Artefakte inklusive Infrastruktur und Apps. Release Prozesse verwenden diese um neue Versionen zu erstellen.

Praxis der Automatisierung, des Merging und des Testings. Hilft Bugs früh in der Entwicklung zu erkennen. Produziert Artefakte, welche in den Release Prozess gespeist werden um regelmässiges deployment zu ermöglichen. Automatisierte Tests.

Planning: Finalisierung der Anforderungen, Updates und neue Änderungen, Architektur und Design, Task Zuteilung, Finalisierung des Zeitplans.

Code: Entwicklung, Finalisierung der Konfiguration, Quellcode einchecken, Statische Codeanalyse, Automatisiertes- und Peer Review.

Build: Kompilieren, Unit Testing, Code-Metriken, Container-Images, Erstellen oder Updaten von Monitor Dashboards

Test: Integrationstests mit anderen Komponenten, Load&Stresstests, UI Tests, Penetrationtests, Requirementtests.

Release: Releasenotes vorbereiten, Version Tagging, Code Freeze, Feature Freeze

Deploy: Updaten der Infrastruktur z.B. Staging, Verifizieren auf Produktion z.B. Smoke Tests

Operate: Dashboard monitoren, Alarm Trigger, Automatisierte kritische Eventhandler, Fehlerlogs überwachen.

Pipeline kann bereits im Quellcode definiert werden. Vorteile à Versionskontrolle, Audit Trails, einfachere Zusammenarbeit (von allen einsehbar), Wissensteilung.

Git Workflows, CD Pipelines, Infrastructur as Code, Tracking und Observability, Containerized Infrastructur

1. Git Repo als Source of Truth für die Applikationskonfiguration und den Code
2. CD-Pipeline ist verantwortlich für builden, testen und deployen
3. Deployment-tool ist verantwortlich für die Applikationsressourcen im Zielsystem
4. Monitoringsystem überwacht Performance und liefert Feedback für das Entwicklerteam.

Unit-Test (Code/Logic - lokal), Integration-Test (Datenbank, Services, Code/Logic - Mit Container), End to End (Alles inklusive UI - mit Pipeline)

Von links nach rechts --> teurer, langsamer, aufwändiger

Ganzheitliches Verifizieren der fachlichen Geschäftsabläufe innerhalb einer Applikation. Simuliert User Experience. Testes komplette Applikation.

10s

Testet verschiedene API-Aufrufe. Prüft, ob mehrere separat entwickelte Komponenten korrekt miteinander funktionieren. Verifiziert die Zusammenarbeit, prüft lediglich Interfaces zwischen zwei oder mehr Komponenten.

1s

Ohne UI, keine Services benötigt. Testen der kleinsten Einheiten. Isoliert von anderen Komponenten. Schnell und wenig Ressourcen, findet nur logische Fehler. Testcode muss einfach sein, Verhalten und nicht Implementation testen, Namen und Struktur testen, deterministisch und isoliert testen, Objektbasiert und mit korrekten Daten.

0.01 – 0.001s

Smoke Tests: Validiert ob die APIs funktionieren

Funktionstests: Testet die funktionalen Anforderungen

Regressionstests: Testet ob neue Änderungen die bestehenden Funktionen der APIs nicht zerstören haben

Loadtests: Testet die Kapazität der Applikation, indem Aufrufe simuliert werden. (Erwartbare Last)

Stresstests: Hohe Belastungen, um die korrekte Funktionalität unter diesen Bedinungen zu testen. (Überlast)

Securitytests: Testen gegenüber externen Bedrohungen

UI Tests: Testet die Funktion zwischen UI und den APIs

Fuzz Tests: Testet mit unerwarteten Daten

Trigger: Startet die Pipeline

Pipeline: Besteht aus einer oder mehreren Stages, kann in eine oder mehrere Umgebungen deployt werden.

Stage: Weg, um Jobs zu organisieren. Eine Stage kann ein oder mehrere Jobs haben.

Job: Jeder Job läuft auf einem Agenten. Job kann auch Agentenlos sein.

Agent: Jeder Agent führt einen Job aus, welcher einen oder mehrere Steps beinhalten kann.

Step: Kann Task oder Script sein. Kleinster Block um Pipeline zu erstellen.

Task: Pre-packaged Script, welches eine Aktion ausführt z.B. Aufruf einer REST-API

Artefakt: Sammlung von Dateien oder Paketen welche bei einer Ausführung erstellt wurden.

azure-pipelines.yml

Code erstellen --> YAML File bearbeiten --> Code in Repo Pushen --> Azure Pipelines --> Deploy to Target

On-Demand Zugriff auf virtualisierte IT-Ressourcen. Innerhalb oder ausserhalb des Rechenzentrums, skalierbar, gemeinsam nutzbar, einfach zu bedienen, über Abo oder nach Bedarf und übers Internet zugänglich.

Klassische IT: Applikation, Daten, Runtime, Middleware, Operating System, Virtualization, Servers, Storage, Networking.

Infrastructur as a Service: Applikation, Daten, Runtime, Middleware

Plattform as a Service: Applikation, Daten

Software as a Service: Alles zur Verfügung gestellt.

IoT, Mobile, Browser

API Gateway

Config Service

Service Registry

Distributed Tracing

Microservices

Server-side Applikation oder Browser App greift auf API zu (einzelner Verbindungspunkt) übersetzt das Protokoll anschliessend für verschiedene Services.

Ein Gateway für jeden Applikationstyp. Übersetzt anschliessend für die verschiedenen Services.

Vorteile --> Isoliert Kunden vom genauen Aufbau der Applikation und den Serverinstanzen, reduziert die Anzahl Anfragen, übersetzt Web-API Protokoll in das gewünschte interne Protokoll.

Nachteile --> grössere Komplexität, zusätzlicher Schritt erhöht Antwortzeit jedoch meist nicht signifikant.

Die Services Registry ist ein Verzeichnis, in dem alle in einer Landschaft bereitgestellten Web-Services publiziert werden können. Unterstützt Load Balance, indem Anfragen auf verschiedene Service-Instanzen verteilt werden (Server-Side, Client-Side)

Distributed Tracing ist eine Methode zum Monitoring von Anwendungen, die auf einer Microservices-Architektur aufsetzen. Verlauf einer Anfrage oder Transaktion kann verfolgt werden, wenn sie die Anwendung durchläuft. So lassen sich Engpässe, Fehler und andere Probleme erkennen, die sich auf die Anwendungsleistung auswirken können.

Der Spring Cloud Config Server bietet eine HTTP-Ressource-basierte API für die externe Konfiguration (Name-Wert-Paare oder gleichwertige YAML-Inhalte). Git Pull à Config Server erstellt verschiedene App Instanzen.

Der Begriff „Cloud-nativ“ bezieht sich auf das Konzept, Anwendungen so zu erstellen und auszuführen, dass man die Vorteile eines verteilten Computings, wie es bei einem Cloud-Bereitstellungsmodell zur Verfügung steht, nutzen kann. Cloud-native Anwendungen werden so entwickelt und erstellt, dass sie die Skalierbarkeit, Elastizität, Resilienz und Flexibilität der Cloud ausnutzen.

DevOps, Continuous Delivery, Microservices, Containers

Unabhängigkeit, Resilienz, Standardisierung, Geschäftsagilität, Automatisierung, keine Ausfallzeiten (Containerverwalter wie Kubernetes).

Verpacken von Softwarecode in Pakete (Paketierung), die sämtliche erforderlichen Komponenten wie Libraries, Frameworks und andere Abhängigkeiten enthalten und in ihrem eigenen „Container" isoliert sind.

Auf diese Weise kann die Software oder Anwendung innerhalb ihres Containers in jede Umgebung verschoben und konsistent auf jeder Infrastruktur ausgeführt werden, unabhängig von der Umgebung oder dem Betriebssystem der Infrastruktur.

Standarisiert Applikationen in Container, leichtgewichtige Virtuele Maschine (ein Host-System-Kernel).