Einleitung

Einleitung

Größe von Mircoservices

Einleitung - Größe von Mircoservices

Zu groß

Größe von Mircoservices - Zu groß

Enthält mehr Fachlichkeit

• Nicht mehr durch ein Team zu managen
• Mehr Abstimmungen
• Mehr Code

Größe von Mircoservices - Zu groß

Zuständigkeiten unklar

• Mehr als ein Team "Owner"
  • Häufig kein Owner
• Broken-Glass-Problematik
  • Aufräumen geht nicht nebenher

Größe von Mircoservices - Zu groß

Struktur kann schnell verloren gehen

• !!!!! Big-Ball-Of-Mud !!!!!

Größe von Mircoservices

Zu klein

Größe von Mircoservices - Zu klein

Refactorings an Schnittstellen

Größe von Mircoservices - Zu klein

Verschieben von Funktionalität

Größe von Mircoservices - Zu klein

Systemintegrationstests mit vielen Teilen

Größe von Mircoservices - Zu klein

Overhead beim Deployment

Größe von Mircoservices - Zu klein

Overhead beim Betrieb

• Monitoring
• Tracing
• Observability
  • teilweise Lizenzierung per JVM

Größe von Mircoservices - Zu klein

Fehlersuche in verteilten Systemen

• Eine Freude!

Größe von Mircoservices - Zu klein

Verteiltes System

• Netzwerk
  • Latenzen
  • Instabilität

Größe von Mircoservices - Zu klein

Verteiltes System

• Komplexität
  • Circuit-Breaker
  • Retries

Größe von Mircoservices - Zu klein

Verteiltes System

• Mehraufwand
  • Asynchrone Kommunikation (Queues/Feeds)
  • Redundante Datenhaltung

Größe von Mircoservices - Zu klein

Verteiltes System

• Fehler bei der Ausführung
  • Kompensation
    • Idempotenz?

Größe von Mircoservices - Zu klein

• Alles nicht so schlimm?
• Gestern, 17:00, Beyond the Saga Pattern Uwe Friedrichsen

Einleitung - Größe von Mircoservices

Zielgröße

• 1 System pro Team (5-9 Leute)
• Möglichst unabhängig von anderen Systemen
  • Self-Contained-Systems / Vertikale
  • Microservices schneiden mit Event-Storming (Ina Einemann / Arne Limburg)

Einleitung - Größe von Mircoservices

Zielgröße

• Keine geeigneten Schnittpunkte?
• Unklare Zuordnungen?
• Im Zweifel: größer
  • Probleme - in der Regel - einfacher zu handhaben

Einleitung

Aufbau innerhalb von Microservices

Einleitung - Aufbau innerhalb von Microservices

Typische Architekturmuster

• Clean Architecture
• Onion Architecture
• Hexagonal Architecture

JMolecules

JMolecules

• Möglichkeit zur Auszeichnung von DDD-Pattern
• Prüfregeln
  • ArchUnit
  • jqassistant

JMolecules

Code diving!

Example Code

Einleitung - Aufbau innerhalb von Microservices

Cohesion vs. Coupling

• Typische Implementierung
  • Je Bounded-Context ein Package auf Domänenebene (meistens)
  • Packages für Applikationsebene nicht mehr fachlich
  • Infrastrukturebene eher technisch geschnitten
    • repositories
    • controller

Einleitung - Aufbau innerhalb von Microservices

Einleitung - Aufbau innerhalb von Microservices

Cohesion vs. Coupling

• Verlust jeglicher fachlicher Bildung
  • Kaum Abhängigkeiten innerhalb der Paketen
  • Viele Abhängigkeiten zwischen den Paketen
• Sichtbarkeit von Klassen, Kontruktoren und Methoden muss fast immer public sein!
• Starten von Integrationstests auf Bounded-Context-Ebene Aufwändig
• Schon ein wenig Dirty!

Einleitung - Aufbau innerhalb von Microservices

Option 1

• Fachliche Ebene zusammenziehen
  • Domain und Service-Package zusammenziehen
  • Öffentliches Interface der Domäne anlegen

Einleitung - Aufbau innerhalb von Microservices

Option 2

• Automatische Prüfungen
  • ArchUnit, jqasistant, ... nutzen um Regeln durchzusetzen

Spring Modulith

Spring Modulith

• Features Spring Modulith
  • Eventing
  • Testing
  • Verification
  • Documentation
  • Observation

Spring Modulith

Code diving!

Example Code

Spring Modulith - Features

Eventing

• Event-Integration-Model (How to invoke Problem)
  • Normal: in derselben Transaktion
  • Async (@Async, @Transactional, @TransactionalEventListener -> @ApplicationModuleListener)
  • Incl. remote with persistent Sender

Spring Modulith - Features

Eventing - Remote

• Transaktionales Versenden zumeist nicht möglich
• EventPublicationRegistry
  • Persistierung von Events in der DB (transaktional)
  • Kein automatisches Fehlerhandling
    • Handling über die Registry möglich

Spring Modulith - Features

Testing

• SpringBootTest per Modul
• Auflösen von Abhängigkeiten
• Support von Events

Spring Modulith - Features

Verification

• Verifikation der Modulabhängigkeiten
• Eclipse und Visual Studio Code Support für Import-Verhinderung

Spring Modulith - Features

Observation

• Metriken nach modulen aufgeschlüsselt

Spring Modulith

Optionen

Spring Modulith - Optionen

Multi-Team-Makro-Service

• Struktur für mehr Code in einer Deployment-Unit
• Test und Überwachung für mehrere Teams trennbar