Die Wahl der Softwarearchitektur ist eine der folgenreichsten Entscheidungen in der Systementwicklung. Sie bestimmt, wie gut sich ein System an neue Anforderungen anpasst, wie stabil es im Betrieb läuft – und wie teuer Veränderungen wirklich werden.

Das Problem: Viele Architekturentscheidungen entstehen nicht aus der Domäne heraus, sondern aus Trends, Tooling oder Erfahrungsmustern. Microservices, Event-Driven oder modularer Monolith werden gewählt, bevor klar ist, welche Anforderungen tatsächlich vorliegen. Die Konsequenzen zeigen sich oft erst später – in unnötiger Komplexität, schwer beherrschbarem Systemverhalten und steigenden Betriebs- und Entwicklungskosten.

In diesem Vortrag zeigen wir, wie sich Architekturentscheidungen systematisch aus fachlichen Anforderungen ableiten lassen – statt sie "zu wählen".

Im Fokus stehen dabei drei zentrale Einflussfaktoren:

  • Prozessmuster der Domäne (z. B. Pipeline vs. Blackboard) und deren Auswirkungen auf Service-Schnitte und Bounded Contexts
  • Konsistenzanforderungen (eventual vs. atomar) und die daraus resultierenden Entscheidungen rund um Orchestrierung, Choreografie und Fehlerbehandlung.
  • Kommunikationsmuster (Events, Commands, synchrone vs. asynchrone Kommunikation) und deren Einfluss auf Latenz, Resilienz und Komplexität.

Anhand konkreter Beispiele diskutieren wir die entscheidenden Trade-offs:

  • Wann ist eine eventgetriebene Architektur sinnvoll – und wann wird sie durch Konsistenzanforderungen unnötig komplex?
  • Welche Patterns wie Saga, Outbox oder Circuit Breaker bringt eine Architektur implizit mit – und was bedeutet das für Betrieb, Debugging und Fehlerszenarien?

Die Teilnehmenden erhalten einen praxisnahen Entscheidungsrahmen, mit dem sich aus Domänenprozessen, Konsistenz- und Kommunikationsanforderungen der passende Architekturstil ableiten lässt – fundiert, nachvollziehbar und ohne Hype-getriebene Bauchentscheidungen.

Für Architekt:innen und Entwickler:innen, die Architektur nicht nur bauen, sondern bewusst entscheiden.