Software-Architekturen: Es muss kein Microservice sein | MVP

Was sind Software-Architekturen?

Software-Architekturen sind die Blaupausen, die ein Projekt wartbar und preiswert halten. Ohne Plan landest du unweigerlich beim berüchtigten 'Spaghetti-Code'.

Stell dir vor, du hast einen Teller Nudeln mit Tomatensauce, merkst aber plötzlich, dass du eigentlich Pesto wolltest. Bei Spaghetti hast du keine Chance – die Sauce klebt überall. Eine gute Architektur ist wie eine Lasagne: Alles ist in sauberen Schichten getrennt. Du kannst die oberste Schicht abnehmen oder austauschen, ohne dass die gesamte Struktur im Chaos versinkt.

Das Ziel: Die Komponenten sollen so wenig wie möglich voneinander wissen. Das bezeichnen wir als Entkopplung.

Wieso Software-Architektur?

Wartbarkeit

Kennst du das? Du sitzt an deiner IDE, klickst auf File > Recent Files und da steht es: Eines deiner ersten Projekte. Du öffnest es und es haut dich aus den Socken. Dieses abgrundtief böse Chaos. Du drückst schneller Strg + F4 als dein KB-schwerer Push das Repository erreichen kann. Du schämst dich vor dir selbst, jemals solch eine chaotische Codebase gebaut zu haben.

Genau hier liegt das erste Argument für Software-Architektur: Wartbarkeit. Und die Freude daran. Niemand hangelt sich gerne wie Tarzan durch die Lianen eines Spaghetti-Code-Dschungels.

Seien wir ehrlich: Nach dem Motto „aus den Augen, aus dem Sinn“ haben wir oft schon nach wenigen Wochen vergessen, wie und warum der Code überhaupt zusammenhält. Wir waren einfach nur froh, dass er funktionierte und magischerweise das tat, wofür er vorgesehen war. Eine gute Architektur jedoch sorgt dafür, dass wir (oder unsere Nachwelt) das System auch in zwei Jahren noch verstehen – es sei denn, man lebt nach dem Motto „nach mir die Sintflut“.

Agilität

Gute Architektur ist das Fundament für echte Agilität. Es entsteht ein spannendes Spiel: Wie schnell kann ich eine Anforderung ändern oder ein Feature hinzufügen, bevor das Kartenhaus ineinanderkracht? Ohne Architektur gewinnen meist die Bugs; mit Architektur bleibt das System auch bei Änderungen stabil.

Kosten

Wer ein MVP (Minimum Viable Product) baut, arbeitet mit begrenzten Ressourcen – allen voran Geld. Ein Microservice-Ansatz ist hier oft ein teurer Luxus. Er läuft verteilt auf verschiedenen Systemen und benötigt eine komplexe Infrastruktur, nur damit man theoretisch „beliebig skalieren“ kann. Doch für ein MVP bedeutet das meistens: Man verbrennt Kapital für Server und Orchestrierung, bevor man überhaupt den ersten zahlenden Kunden hat. Architektur hilft dabei, die Kosten im Griff zu behalten, indem man so einfach wie möglich, aber so strukturiert wie nötig startet.

Software-Architekturen bilden oft die Teamstruktur ab. Conway’s Law besagt im Kern: Das System, das du baust, wird am Ende so aussehen wie die Kommunikationswege in deiner Firma. Microservices sind super, wenn man 5 Teams in 5 verschiedenen Zeitzonen koordinieren muss. Für einen Solo-Dev oder ein 3er-Team ist ein solches Konstrukt jedoch technischer Selbstmord.

Stattdessen gibt es Alternativen, die fast genauso gut skalieren und – falls nötig – später sauber in einzelne, verteilte Services aufgebrochen werden können.

Bevor wir also blind dem Hype folgen, schauen wir uns die verschiedenen Konzepte einmal genauer an:

Grundlegende Architektur Typen

Der Big Ball of Mud

Er ist das gefürchtete Spaghetti-Monster: schwer wartbar, starr und fehleranfällig. Er ist das Symptom einer ungeplanten, "wild gewachsenen" Implementierung. Meist fängt es als simples Skript an, das dann wie eine Lawine Fahrt aufgenommen hat und immer weiter angeschwollen ist. Dieser Architekturtyp leidet unter massiven Deployment-Problemen, mangelnder Testbarkeit und mieser Performance. Ein wahres Anti-Pattern.

Am besten stellt man sich das so vor: Du sitzt im Kindergarten und bittest dein Kind, ein Porträt von dir zu malen. Was du zurückbekommst, ist ein Kreis mit lauter wirren Strichen, die kreuz und quer überallhin führen. Genau so fühlt sich dieser Code an.

Client/Server (The Classic)

Das Grundprinzip der Trennung von Aufgaben (Separation of Concerns). Hier teilt man das System in zwei Rollen auf: Der Client fragt an, der Server liefert.

• Two-Tier (Client & Server): Die einfachste Form. Die Logik sitzt entweder komplett auf dem Client (Fat Client) oder auf dem Server.
• Desktop + Datenbank-Server: Der Klassiker für interne Firmensoftware. Die Anwendung läuft auf dem PC und spricht direkt mit einer zentralen SQL-Datenbank.
• Browser + Web-Server: Das Fundament des Internets. Dein Browser ist der (meist "Thin") Client, der Server liefert HTML, CSS und Daten.

Three-Tier (Die Schichtentrennung)

Hier gehen wir einen Schritt weiter und führen eine dedizierte Ebene für die Business-Logik ein. Man trennt strikt in:

1. Presentation Tier (Die Benutzeroberfläche)
2. Logic Tier (Hier passiert die Magie, die Berechnungen und Validierungen)
3. Data Tier (Die persistente Speicherung, meist eine Datenbank)

Diese Struktur ist der Urvater der sauberen Architektur und sorgt dafür, dass du die Datenbank austauschen kannst, ohne deine gesamte UI neu schreiben zu müssen.

Distributed Systems (Verteilte Systeme)

Verteilte Systeme sind die Antwort auf die Frage: „Wie skaliere ich ins Unendliche?“ Anstatt eines einzelnen, riesigen Servers lässt man viele kleine Einheiten miteinander kommunizieren.

Arten

Es gibt eine Fülle an Architekturen in diesem Bereich: Service-based, Event-driven, Space-based oder die klassische Service-oriented Architecture (SOA). Wir wollen uns hier aber auf den aktuellen „Industrie-Standard“ konzentrieren:

Microservice Architektur

Bei Microservices wird die Anwendung in kleine, unabhängige Einheiten zerlegt, die jeweils eine spezifische Geschäftsfunktion (Bounded Context) abbilden. Sie kommunizieren meist über das Netzwerk (REST, gRPC, Message Broker).

Vorteile

• Skalierbarkeit: Du kannst den „Payment-Service“ 100-mal klonen, während der „E-Mail-Service“ nur einmal läuft.
• Technologie-Freiheit: Service A kann in Rust geschrieben sein, Service B in Go und Service C in Python.
• Unabhängiges Deployment: Ein Bugfix im Login-Service erfordert keinen Neustart des gesamten Systems.

Nachteile

• Extreme Komplexität: Du tauschst Code-Komplexität gegen Infrastruktur-Komplexität.
• Observability: Wenn ein Request fehlschlägt, musst du ihn durch 10 verschiedene Services tracen, um den Fehler zu finden.
• Daten-Konsistenz: „Eventual Consistency“ ist die neue Realität – Daten sind nicht überall sofort aktuell.

Die harten Fakten: Die Irrtümer verteilter Systeme

Entwickler unterliegen beim Entwurf verteilter Systeme gerne folgenden Irrtümern, die das Projekt schneller ruinieren können als jeder Syntax-Fehler:

Monolithen: Felsenfeste Basis statt Relikt der Vergangenheit

Monolithen sind wie riesige, felsenfeste Steine. Man hat das Gefühl, man könnte Bomben darauf werfen und sie hielten trotzdem zusammen. Für viele wirken sie wie ein Überbleibsel einer vergangenen Epoche, als Computer noch raumgroß und sündhaft teuer waren – oder eben wie „Anfängerkram“. Dabei wird völlig zu Unrecht auf sie herabgesehen. Gerade in der Entwicklung von MVPs sind sie oft die vernünftigste Wahl.

Die verschiedenen Arten

• Klassischer Monolith: Das (leider oft anzutreffende) Spaghetti-Monster.
• Layered Architecture (N-Tier): Die klassische Schichentrennung (UI, Business-Logik, Datenbank).
• Pipeline-Architektur: Daten fließen durch eine Kette von Transformatoren.
• Microkernel-Architektur: Ein schlanker Kern mit Plug-ins (wie deine IDE oder ein Betriebssystem).

Die Wunderarchitektur: Der Modulith (Modularer Monolith)

Stell dir einen Modulithen wie eine Pizza oder einen Kuchen vor. Der Clou: Die Stücke sind bereits vorgeschnitten, liegen aber noch gemeinsam auf einem Karton.

Du kannst den Kuchen als Ganzes servieren (ein einziges Deployment). Wenn du aber später merkst, dass ein Teil (z. B. der Auth-Service) extrem viel Last zieht, nimmst du dieses eine Stück einfach weg und stellst es auf einen eigenen Teller (einen eigenen Server). Das kannst du tun, ohne den Rest des Kuchens zu zerstören.

Die technischen Benefits:

• Compile-Time-Safety: Im Modulithen meckert dein Compiler sofort, wenn eine Schnittstelle nicht passt. Bei Microservices merkst du die Misere oft erst durch einen Laufzeit-Error in der Produktion.
• Geringe kognitive Last: Du musst nicht zwischen zehn Repositories, hunderte Docker-Containern und komplexen Deployment-Pipelines hin- und herspringen. Dein Fokus bleibt beim Code.
• Refactoring-Freundlichkeit: Mal eben eine Methode umbenennen? In einem Modulithen ein Klick in der IDE. In einer Microservice-Welt ein koordinierter Release-Plan über drei Teams hinweg.

Wie lerne ich Software-Architektur?

Theorie ist gut, aber Architektur lernt man vor allem durch Schmerz – und durch das Studium derer, die diesen Schmerz schon hinter sich haben.

Hands-On

Baue Projekte. Nicht nur eins, sondern mehrere. Versuche, ein altes Projekt von dir umzustrukturieren. Erst wenn du merkst, wie weh es tut, eine Komponente auszutauschen, verstehst du, warum Entkopplung so wichtig ist.

Bücher

Die Klassiker sind zeitlos. Achte auf Sales (wie bei Humble Bundle), dort gibt es oft ganze Pakete für wenig Geld. Meine Empfehlungen:

• "Clean Architecture" von Robert C. Martin (Der Klassiker für Schichtentrennung).
• "Fundamentals of Software Architecture" von Mark Richards (Perfekt für den Überblick über die Muster).
• "Building Microservices" von Sam Newman (Damit du weißt, worauf du dich einlässt).

Podcasts

Hören statt Lesen. In meiner handverlesenen Liste der besten Tech-Podcasts findest du Experten-Talks, die tief in Architektur-Themen eintauchen.

YouTube-Videos

Kanäle wie Modern Software Engineering oder CodeOpinion sind Goldgruben für pragmatische Architektur-Tipps.

KI für Software-Architektur (Vorsicht)

Agentic AI ist der Helfer, den jeder wollte – manchmal aber auch so anstrengend wie wir Junior-Entwickler auf Koffein-Entzug. In meinen Frontend-Projekten setze ich gerne Agenten ein, nachdem ich ein festes Konzept vorgegeben habe. Das kann klappen – oder völlig schiefgehen.

Gerade im Flutter-Umfeld, wo ich mit BLoCs (State Management) arbeite, um die Business-Logik strikt von der UI zu trennen, erlebe ich oft Folgendes: Die KI wirft meine Vorgaben, den Logic-Layer sauber zu nutzen, vehement über Bord und klatscht Logik direkt in die Widgets. Ende vom Lied: Ich drücke Undo und schreibe es selbst.

Interessanterweise sagen mir viele, ihre KI würde das nie tun und sich brav an den Kontext (instruction.md und Co.) halten. Vielleicht mag sie meine Apps einfach nicht?

Chancen

Die größte Chance ist das Lernen durch KI. Sie kann dir Konzepte blitzschnell erklären oder Beispiele generieren. Aber Vorsicht: Die Qualität schwankt massiv. Mal bekommst du den "Best Practice"-Weg, mal nur das Basis-Paket, das in einen "Premium Business Look" verpackt wurde. Hier helfen unter Umständen ChatGPT Personas, mit denen du die Instruktion gibst, dass es sich um einen hochklassigen Software-Architekten handelt, der Bücher wie Clean Code, Clean Architecture und Co. nicht nur gelesen hat, sondern seine Manifeste darstellen.

Risiken

KI liefert oft Code-Snippets, die isoliert betrachtet funktionieren, aber architektonisch „lose“ im Raum stehen. Wer nur noch "Vibe-Coding" betreibt, baut unbewusst einen Monolithen, der so verstrickt ist, dass ihn keine Architektur der Welt mehr rettet.

Nochmal meine Flutter-Arbeit als Beispiel: Mir passierte das bei einem Flutter-Projekt: Ich wollte UI und Logik (Events, States, BLoCs) sauber trennen. Die KI lieferte mir erst nur eine "BLoCs-Light"-Komponente. Erst durch die offizielle Dokumentation merkte ich, dass es mit Tools wie Freezed (ein Code-Generator für Datenklassen) viel effektiver und wart