Softwarearchitektur (arc42, iSAQB, Microservices, DDD)

Softwarearchitektur ist für mich kein Diagramm, das einmal gezeichnet und dann vergessen wird. Sie besteht aus drei Dingen, die zusammengehören: einer strukturierten Dokumentation mit arc42, einer klaren Review-Methodik auf Basis des iSAQB-Lehrplans und sauberen Domainschnitten in Microservice-Landschaften. Prinzipien aus dem Domain-Driven Design, etwa saubere Bounded Contexts und eine gemeinsame fachliche Sprache, fließen dabei pragmatisch mit ein – mehr dazu weiter unten.

Softwarearchitekt mit arc42-Erfahrung: Dokumentation als Arbeitswerkzeug

arc42 ist seit mehr als 15 Jahren mein Standard-Template für Architekturdokumentation. Ich habe es in Projekten bei comSysto, codecentric, Audi und MAN genutzt. Der Grund ist einfach: arc42 gibt eine feste Struktur vor, ohne eine bestimmte Technologie oder Vorgehensweise zu erzwingen. Jeder im Team weiß, wo die Qualitätsziele stehen, wo der Kontext des Systems beschrieben ist und wo Entwurfsentscheidungen mit ihrer Begründung festgehalten werden.

Wie gut das auch abseits klassischer Kundenprojekte funktioniert, zeigt ketovavaria.de, ein Blog, der von KI-Agenten betrieben wird. Dort pflegt das Team eine vollständige arc42-Dokumentation mit 13 Kapiteln, die der Architektur-Agent laufend aktuell hält. Für mich ist das ein guter Beleg dafür, dass eine klare Dokumentationsstruktur nicht nur Menschen hilft, sondern auch Agenten, die gemeinsam an einem System arbeiten.

iSAQB-Zertifizierung: das methodische Fundament für Architektur-Reviews

Am 06.12.2013 habe ich in München die Prüfung zum iSAQB Certified Professional for Software Architecture – Foundation Level (CPSA-F) abgelegt. Der Lehrplan deckt genau die Bereiche ab, die in einem Architektur-Review zählen: Qualitätsanforderungen, Entwurfsentscheidungen, Kommunikation und Dokumentation sowie die Bewertung von Architekturen.

In der Praxis beginne ich ein Review immer bei den Qualitätsmerkmalen. Bevor wir über eine Lösung sprechen, legen wir gemeinsam mit dem Team fest, was wirklich zählt: Wartbarkeit, Performance, Sicherheit oder etwas anderes. Erst danach messe ich die Lösung an diesen Zielen. So wird aus einem Review keine Geschmacksdiskussion, sondern eine nachvollziehbare Bewertung.

Mindestens genauso wichtig ist die Kommunikation mit den verschiedenen Stakeholdern. Fachbereich, Entwicklung und Betrieb stellen unterschiedliche Fragen an eine Architektur und brauchen unterschiedliche Antworten. Hier schließt sich der Kreis zu arc42: Die Gliederung hilft, für jede Zielgruppe die passende Sicht bereitzuhalten.

Microservices-Domainschnitt in der Praxis: Fachlichkeit vor Framework

Seit über 15 Jahren entwerfe ich Microservice-Architekturen, unter anderem bei comSysto, codecentric, Audi und MAN. Meine wichtigste Erkenntnis daraus: Ein sauberer Domainschnitt ist wichtiger als jede Technologieentscheidung. Ein falsch geschnittener Service bleibt falsch geschnitten, egal mit welchem Framework er gebaut ist, etwa mit Java und Spring.

Deshalb beginnt der Entwurf bei der Fachlichkeit und nicht bei Frameworks. Die zentralen Fragen lauten: Welche Verantwortung gehört zusammen? Wo liegen die natürlichen Grenzen zwischen den Domänen? Ein verlässliches Warnsignal für unsaubere Grenzen ist, wenn eine fachliche Änderung regelmäßig mehrere Services gleichzeitig betrifft. Dann ist die Kopplung zu hoch, und der Schnitt sollte überprüft werden.

Domainschnitt und Auslieferung: warum Canary-Releases dazugehören

Für mich gehören Domainschnitt und Auslieferungsstrategie zusammen. Klare Domänengrenzen sind die Voraussetzung dafür, dass Services unabhängig voneinander ausgeliefert werden können. Erst dann werden Verfahren wie Canary-Releases sinnvoll, bei denen eine neue Version zunächst nur für einen Teil der Nutzer ausgerollt wird, etwa auf Kubernetes/EKS. Beide Seiten habe ich in Fachartikeln beschrieben: in „Microservices und die Jagd nach mehr Konversion“ (Java Aktuell, 2015) und in „Canary-Releases mit der Very Awesome Microservices Platform“ (Java Aktuell, 2016).

Domain-Driven Design: pragmatisch angewendet, formale Methode als nächster Schritt

In 15 Jahren Microservice-Architektur habe ich die Kernfragen des Domain-Driven Design immer wieder praktisch beantwortet, auch ohne das formale Vokabular: Welche fachliche Verantwortung gehört zusammen? Wo verläuft die Grenze zwischen zwei Domänen? Wer hält die Datenhoheit? Genau das sind die Fragen, die auch Bounded Contexts und Ubiquitous Language beantworten sollen – ich bin nur über die Praxis dorthin gekommen statt über das Buch.

Die Theorie kenne ich gut: Ubiquitous Language, Bounded Contexts und Aggregates, wie Eric Evans sie 2003 beschrieben hat. Was ich bisher nicht formal durchgeführt habe, sind die benannten Workshop-Formate wie Event Storming oder ausformulierte Context Maps als eigenständige Artefakte – diese Werkzeuge machen implizites Wissen im Team explizit und teilbar, statt es nur in einem Kopf zu halten.

Genau das ist für mich der konkrete nächste Schritt: DDD nicht als neue Theorie lernen, sondern die vorhandene Praxis-Intuition für Domänengrenzen mit den formalen Methoden absichern und im Team gemeinsam nutzbar machen – etwa durch ein Event Storming beim nächsten passenden Projekt.

Wie die drei Themen zusammenspielen

arc42 liefert die Struktur, in der Architekturentscheidungen festgehalten werden. Die iSAQB-Methodik sorgt dafür, dass diese Entscheidungen an vorher vereinbarten Qualitätszielen gemessen werden. Die Domainschnitt-Praxis bestimmt, wie das System fachlich zerlegt wird, und damit, ob Teams und Services unabhängig arbeiten und ausliefern können. Domain-Driven Design rundet das ab: die formale Methodik für Domänengrenzen, die ich bisher pragmatisch aus Erfahrung ziehe.