Crashkurs Softwarearchitektur für Webentwickler:innen

Nils Röhrig | JavaScript & Angular Days 2026 | München

Nils Röhrig, 39
Freiberuflicher Speaker, Trainer und Autor
Hauptberuflich Software Engineer @ Loql

Der Trainer

https://my.hidrive.com/share/l-ddkun8jn

Fragen die es zu beantworten gilt

Was ist Softwarearchitektur?
Wie erstelle ich eine initiale Software-Architektur?
Welche Art von Tools kann ich direkt in meiner Arbeit nutzen?
Warum ist Softwarearchitektur wichtig für mich als Webentwickler:in?

Was ist Softwarearchitektur?

Eine Definition zu finden ist hart.

Software ändert sich ständig.

Good Practices ändern sich.

ISO-Definition von Softwarearchitektur

Die Gesamtheit der zugrundeliegenden, intrinsischen Konzepte und Eigenschaften eines Systems in seiner Umgebung, realisiert durch seine Elemente und Beziehungen, sowie die Prinzipien seines Entwurfs und seiner Weiterentwicklung.

Quelle: Rücker + Schindele – ISO 42010 Kurzreferenz

ISO-Definition von Softwarearchitektur

Wichtige Bestandteile nach ISO

Das System
als Ganzes.

Die Umgebung des Systems.

Elemente & Beziehungen

Die Entwurfs-prinzipien.

Das System in seiner Umgebung

Die Elemente des Systems und deren Beziehungen (1/2)

Die Elemente des Systems und deren Beziehungen (2/2)

Die Entwurfsprinzipien des Systems

Jedes Softwareprojekt ist unterschiedlich!

Architecture is about the important stuff. Whatever that is.

— Ralph Johnson

Quelle: Martin Fowler – Who Needs an Architect?

Aber was ist »the important stuff«?

Architecture is the set of decisions that are hard to change.

— Martin Fowler

Quelle: Martin Fowler – Who Needs an Architect?

Was ist also Architektur?

Was auch immer in deiner Software wichtig und später schwer zu ändern ist!

Ein bewegliches Ziel, dass sich über Zeit verändert.

Etwas, dass immer da ist – kontrolliert oder unkontrolliert.

Wie finde ich raus, was wichtig und schwer zu ändern ist?

Ein Ansatz für die Entwicklung einer initialen Architektur

Quelle: Mark Richards & Neil Ford: Fundamentals of Software Architecture

Qualitätsmerkmale von Softwaresystemen

In der Vergangenheit bekannt als
Nicht-Funktionale Anforderungen

Im englischen Sprachgebrauch Architecture Capabilities.
Oft auch einfach die -ilities des Systems

Leitfrage: Wie gut ist das System darin, seine fachlichen Aufgaben zu erfüllen?

Qualitätsmerkmale des LASR-Qualitätsmodells

Unterstützungsmaterial aus der LASR-Community

Initiale logische Architektur

Aufteilung des Systems in initiale Komponenten die logisch zusammenhängende Verantwortlichkeiten abbilden.

Informiert durch fachliche Anforderungen, zu erwartende Nutzergruppen und weitere Rahmenbedingungen.

Ziel ist ein erster Entwurf. Spätere Änderungen sind zu erwarten und sehr wahrscheinlich.

Beispiel einer initialen logischen Architektur

Quelle: Mark Richards – Software Architecture Monday, Lesson 193

Architekturstile

Die grundlegene Struktur des Systems.

Fachlicher oder technischer Schnitt.

Monolithisch
oder Verteilt.

Eigenschaften von Architekturstilen

Eigenschaft	Geschichteter Monolith	Modularer Monolith	Microkernel	Microservices	Servicebasiert	Serviceorientiert	Ereignisgesteuert	Space-Based
Schnitt	Technisch	Fachlich	Technisch	Fachlich	Fachlich	Fachlich	Technisch	Technisch
Kosten	💲	💲	💲	💲💲💲💲💲	💲💲	💲💲💲💲	💲💲💲	💲💲💲
Wartbarkeit	⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐
Testbarkeit	⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐	⭐
Deploybarkeit	⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐
Simplizität	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐⭐	⭐	⭐⭐	⭐
Skalierbarkeit	⭐	⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Elastizität	⭐	⭐	⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Responsivität	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Fehlertoleranz	⭐	⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Evolvierbarkeit	⭐	⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Abstraktion	⭐	⭐	⭐⭐⭐	⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐
Interoperabilität	⭐	⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐

Quelle: Architecture Styles Worksheet V2.0, erstellt von Mark Richards, DeveloperToArchitect.com

Geschichteter Monolith

(Topologie)

Geschichteter Monolith (Pro & Contra)

Schwache operative Eigenschaften wie Skalierbarkeit & Fehlertoleranz.
Fachliche Änderungen betreffen schnell mehrere Schichten.
Reduzierte Performance, weil Anfragen durch alle Schichten müssen.

Simple Struktur, einfach zu verstehen.
Geringe Kosten für die initiale Entwicklung.
Austausch ganzer Schichten möglich.
Reduzierte Abhängigkeit zwischen Komponenten unterschiedlicher Schichten.

Modularer Monolith

(Topologie)

Modularer Monolith (Pro & Contra)

Schwache operative Eigenschaften wie Skalierbarkeit & Fehlertoleranz
Technische Änderungen können schnell viele Domänen betreffen

Simple Struktur, einfach zu verstehen
Geringe Kosten bei der initialen Entwicklung
Fachliche Änderungen minimalinvasiv anwendbar

Microservices

(Topologie)

Microservices (Pro & Contra)

Sehr komplex, schwer zu verstehen.
Sehr hohe Kosten.
Aufspaltung des Datenmodells erforderlich.
Serviceübergreifende Kommunikation kostet Performance.
Erfordert passende Organisationsstruktur.

Services sind vollständig unabhängig voneinander.
Starke operative Eigenschaften wie Skalierbarkeit & Fehlertoleranz.
Services sind die einzigen Eigentümer ihrer Daten.

Let's Build an Architecture!

Whiteboard für Kon-Fu

Quelle: Übersetzung der All Stuff, No Cruft! Kata

Welche Qualitätsmerkmale sollte Kon-Fu aufweisen?

Anpassbarkeit /
Customizability

Komponentenfindung mit dem Actor/Action-Ansatz

Akteure und Aktionen

Mitarbeiter:in

Konferenz erstellen

Konferenz branden

Programm gestalten

Raum zuweisen

System

Aktualisierungen senden

Teilnehmer:in

Folien einsehen

Programm einsehen

Raumzuweisung sehen

Vortrag bewerten

Aktualisierungen anfordern

Vortrag einreichen

Vortrag bearbeiten

Folien bereitstellen

Referent:in

Initiale Komponenten

Vortragsbe-

reitstellung

Konferenz-

erstellung

Konferenz-

branding

Programm-
gestaltung

Vortrags-

bewertung

Benach-
richtigung

Mitarbeiter:in

Konferenz erstellen

Konferenz branden

Programm gestalten

Raum zuweisen

System

Aktualisierungen senden

Vortrag einreichen

Vortrag bearbeiten

Folien bereitstellen

Referent:in

Teilnehmer:in

Folien einsehen

Programm einsehen

Raumzuweisung sehen

Vortrag bewerten

Aktualisierungen anfordern

Initiale logische Architektur für Kon-Fu

Recap der Eigenschaften von Architekturstilen

Eigenschaft	Geschichteter Monolith	Modularer Monolith	Microservices
Schnitt	Technisch	Fachlich	Fachlich
Kosten	💲	💲	💲💲💲💲💲
Wartbarkeit	⭐	⭐⭐	⭐⭐⭐⭐⭐
Testbarkeit	⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Deploybarkeit	⭐	⭐⭐	⭐⭐⭐⭐⭐
Simplizität	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐
Skalierbarkeit	⭐	⭐	⭐⭐⭐⭐⭐
Elastizität	⭐	⭐	⭐⭐⭐⭐
Responsivität	⭐⭐⭐	⭐⭐⭐	⭐⭐
Fehlertoleranz	⭐	⭐	⭐⭐⭐⭐⭐
Evolvierbarkeit	⭐	⭐	⭐⭐⭐⭐⭐
Abstraktion	⭐	⭐	⭐
Interoperabilität	⭐	⭐	⭐⭐⭐

Wahl des Architekturstils

Qualitätsmerkmal

Benutzbarkeit

Performanz

Anpassbarkeit /
Customizability

Kompatibilität

Skalierbarkeit

Geeigneter Stil

alle

Monolith

Microservices

alle

Also Microservices, oder was?

Machbarkeit im Hinterkopf behalten!

Annahmen mangels Kontext:

Kleine IT-Abteilung
Enges Budget
Wenig Veränderung in den Features

Modularer Monolith
möglicherweise attraktiver

Nützliche Muster für Entwickler:innen

Architekturentscheidungen sind schwer zu ändern.

Damit muss das Ziel von Architektur sein, schwer Änderbares leicht änderbar zu machen!

Warum sind Dinge schwer zu ändern?

Geringe Kohäsion

Enge Kopplung

Architekturmuster

Können die Entkopplung von Software-Komponenten erleichtern und deren Kohäsion steigern.

Unterstützung für die Strukturierung des Codes von Software-Komponenten oder -Systemen.

Beispiele: Ports-and-Adapters,
Feature-Sliced Design.

Ports-and-Adapters

Quelle: Tom Hombergs: Hexagonal Architecture with Java and Spring

(Topologie)

Das Hexagon bildet den Kern des Bausteins und enthält die Fachlogik.

Eingehende Ports beschreiben den Zugriff auf den Kern von außerhalb

Abhängigkeiten im Quellcode zeigen von außen nach innen.

Augehende Ports beschreiben den Zugriff des Kerns auf externe Dienste (Dependency Inversion).

Eingehende Adapter
nutzen eingehende Ports um mit dem Kern zu interagieren

Anwendungsfälle im Kern implementieren eingehende Ports und nutzen ausgehende Ports. Passende Adapter werden via Dependency Injection von außen bereitgestellt.

Ports-and-Adapters (Anwendungsgebiete)

Wann immer hohe Modularisierung und Änderbarkeit erforderlich ist.

Anwendungen mit langlebigen fachlichen Strukturen.

Anwendungen mit mehreren verschiedenen Zugangswegen.

Feature-Sliced Design

Die Anwendung ist in Layers aufgebaut, die nach Scope gegliedert sind.

Abhängigkeiten im Quellcode zeigen von oben nach unten.

Layers teilen sich in Slices auf, die nach Verantwortlichkeit
gegliedert sind.

Abhängigkeiten
zwischen Slices im gleichen Layer sind unerwünscht.

Layers teilen sich in Slices auf, die nach Verantwortlichkeit
gegliedert sind.

Slices teilen sich in Segments auf, die nach Zweck geglie-dert sind

Abhängigkeiten

zwischen Segments im gleichen Slice sind erlaubt.

Feature-Sliced Design

(Konzepte)

Quelle: Feature-Sliced Design Dokumentation

Feature-Sliced Design (Topologie)

Quelle: Felix Abele – Feature-Sliced Design and what we need for good frontend architecture

Feature-Sliced Design (Anwendungsgebiete)

Frontend-Anwendungen
(Web, Mobile, ...)

Bedarf nach wohldokumentierter Struktur und Einheitlichkeit

Wunsch nach vorhandener Tooling-Unterstützung (steiger)

Warum ist das wichtig?

Architektur bestimmt, wie gut dein System wartbar, erweiterbar
und verständlich ist.

Gute Struktur erhöht Entwicklungsgeschwindigkeit und reduziert
Fehler bei Änderungen.

Sie verbessert Zusammenarbeit und Skalierbarkeit
in deinem Team.

Sie schafft Leitplanken für Designentscheidungen
und Code-Qualität.

Dank LLMs ist Code billig und schnell erstellt. Struktur, Konsistenz und langfristige Steuerbarkeit bleiben jedoch in deiner Verantwortung.

Übung

https://github.com/nilsroehrig/jsdays-2026-architecture-crashcourse

Beipiellösungen

Thank You!

Bluesky:

LinkedIn:

E-Mail:

Code:

nilsroehrig

info@nilsroehrig.de

@nilsroehrig.dev

GitHub

Lucide License

ISC License

Copyright (c) for portions of Lucide are held by Cole Bemis 2013-2026 as part of Feather (MIT). All other copyright (c) for Lucide are held by Lucide Contributors 2026.

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The MIT License (MIT) (for portions derived from Feather)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.