Simon KleinSoftware-Architekt & Fullstack-Entwickler für .NET-Systeme, die mitwachsen

Viele Systeme wachsen über Jahre, ohne dass die Architektur mitgedacht wird — neue Features werden angeflanscht, bis jede Änderung zum Risiko wird. Genau hier setze ich an: beim Zuschnitt von Domänen, bei der Entscheidung, wo ein Monolith noch sinnvoll ist und wo Microservices echten Mehrwert bringen, und bei der Frage, wie Komponenten so geschnitten werden, dass sie unabhängig wachsen können.

Dabei geht es selten um die grüne Wiese, sondern meist um Entscheidungen innerhalb gewachsener, teils komplexer Strukturen — Modernisierung statt Neubau. Bei meinen Projekten wie Edvora treffe und verantworte ich sämtliche Architekturentscheidungen selbst, von der Domänenmodellierung bis zur technischen Umsetzung.

Das Ergebnis, das ich anstrebe: Systeme, deren nächste Änderung nicht zum Risiko wird, sondern zur erwartbaren Erweiterung.

Ein Backend muss zwei Dinge gleichzeitig leisten: heute zuverlässig laufen und morgen erweiterbar bleiben. Ich entwickle Services in C# / .NET mit Fokus auf klare Verantwortlichkeiten pro Service, saubere Schnittstellen und Nachvollziehbarkeit im Code — nicht nur, damit es funktioniert, sondern damit der nächste Entwickler (oder ich selbst in sechs Monaten) versteht, warum es so gebaut ist.

Für die Kommunikation zwischen Services setze ich, wo sinnvoll, auf asynchrone statt enge, synchrone Abhängigkeiten — das entkoppelt Systeme und macht sie robuster gegenüber Ausfällen einzelner Komponenten. Containerisierung mit Docker sorgt dafür, dass Umgebungen reproduzierbar sind, von der lokalen Entwicklung bis zum Deployment.

Ich arbeite dabei nicht nur als reiner Entwickler, sondern denke die Architektur-Entscheidungen von Anfang an mit — Backend-Entwicklung und Systemarchitektur sind für mich kein Gegensatz, sondern zwei Seiten derselben Arbeit.

Eine gute Backend-Architektur nützt wenig, wenn die Anbindung ans Frontend zum Flickenteppich wird. Ich entwickle Oberflächen in React mit TypeScript, die bewusst auf die dahinterliegende Backend-Architektur abgestimmt sind — statt Frontend und Backend getrennt zu denken und hinterher mühsam zusammenzuführen.

Das bedeutet konkret: typsichere Schnittstellen zwischen Frontend und Backend, Zustandsverwaltung, die zur tatsächlichen Datenarchitektur passt, und Komponenten, die genauso wartbar aufgebaut sind wie die Services im Hintergrund. Bei Edvora etwa ziehe ich diesen Ansatz konsequent durch: Vom Datenbankschema bis zur Nutzeroberfläche liegt jede Entscheidung in einer Hand.

Für Auftraggeber heißt das: ein Ansprechpartner für den gesamten Stack, keine Reibungsverluste an der Schnittstelle zwischen Frontend- und Backend-Team.

Nicht jedes Projekt braucht sofort Code — manchmal ist die wichtigste Arbeit, die richtige Frage zu stellen, bevor die erste Zeile geschrieben wird: Welche Architektur trägt die nächsten drei Jahre? Wo lohnt sich Modernisierung, wo reicht ein gezielter Eingriff?

Mein Vorgehen dabei folgt einem klaren Muster: erst die fachlichen Anforderungen und Constraints verstehen, dann Optionen mit ihren Trade-offs gegenüberstellen, statt vorschnell eine Lösung festzulegen. Entscheidungen dokumentiere ich nachvollziehbar, damit sie auch Monate später noch verständlich sind — für mich selbst und für jeden, der später am System weiterarbeitet.

Fachlich abgesichert wird das durch meine iSAQB-Zertifizierungen (Foundation, FLEX). Das Ergebnis ist keine abstrakte Strategie-Folie, sondern eine Einschätzung, die sich direkt in konkrete, umsetzbare nächste Schritte übersetzen lässt.