Architektur
Die Sprache und die Entscheidungen des Systementwurfs.
Was Architektur umfasst
Softwarearchitektur ist die Menge der Entscheidungen über die Struktur eines Systems, die teuer zu ändern sind. Diese Kategorie behandelt, wie man Grenzen zieht, Komponenten schneidet und Entscheidungen bewusst trifft.
Was diese Kategorie abdeckt
- Modulare Monolithen und Microservices
- Ereignisgetriebene Architektur
- Bounded Contexts sauber schneiden
- Anti-Pattern: der verteilte Monolith
Belastbare Antworten in diesem Feld.
Tiefe, referenzierbare Dokumente — jede Empfehlung mit Trade-off, Kosten und dem Fall, in dem wir anders entscheiden.
Software, die in zehn Jahren noch läuft
Welche Engineering-Entscheidungen Software zehn Jahre tragfähig halten — Kopplung, Umkehrbarkeit, Betrieb, Standards — jeweils mit ihren Abwägungen.
Reversibilität vor Vorhersage
Man kann die Zukunft nicht vorhersagen — also Änderung billig halten statt darauf zu wetten. Welche Entscheidungen man verlangsamt und umkehrbar baut.
Business-Logik gehört nicht in Controller
Warum Geschäftsregeln in eine framework-unabhängige Domänenschicht gehören, nicht in den Controller: Symptome, Wartungskosten, Testbarkeit, Migration.
Ausgereifte Technik vor Neuheit
Technologiewahl ohne Mode: Warum Reife heißt, dass andere die Fehler schon fanden — was das Neue verbirgt, wann es trotzdem richtig ist. Kontext und Lebensdauer.
Modularer Monolith vs. Microservices
Kein Glaubenskrieg, sondern eine Entscheidung über die Verteilung von Komplexität: Was ein modularer Monolith ist, wann Microservices objektiv besser sind.
Build, Buy oder Configure — wann Individualsoftware sich rechnet
Selbst bauen, kaufen oder konfigurieren — ehrlich, auch wenn die Antwort 'kaufen' lautet. Das Kriterium: Differenzierung und Lebensdauer, verborgene Kosten.
Warum Softwareprojekte wirklich scheitern
Softwareprojekte scheitern selten an Technologie, sondern weil Engineering-Entscheidungen unumkehrbar werden, bevor das Problem verstanden ist.
Serverseitiges Rendering oder SPA
Serverseitig gerendert oder SPA — die Frontend-Wahl, die über die Zehn-Jahres-Wartbarkeit entscheidet. Nach Interaktivität und Lebensdauer, nicht nach Mode.
Legacy-Modernisierung ohne Big Bang
Wie man ein Produktivsystem inkrementell und umkehrbar ablöst statt per Rewrite: Strangler Fig, Anti-Corruption Layer, Datenmigration, Parallelbetrieb.
Ein Legacy-System übernehmen — die ersten 90 Tage
Die Übernahme eines Systems, das man nicht gebaut hat: zuerst verstehen statt ändern, Sicherheitsnetze vor dem ersten Eingriff, die Karte, das Verhalten festhalten.
Wann ein Rewrite die falsche Entscheidung ist
Warum ein Rewrite eingebettetes Wissen verwirft und ein bewegliches Ziel jagt, wann ein Neubau doch richtig ist — und warum schrittweise fast immer besser ist.
Gelernte Lektionen in diesem Feld.
Fehler und was sie uns gelehrt haben — anonym, ohne Drama. Der Fehler ist der Lehrer.
5000 Zeilen Copy & Paste
Ein Praxisbericht: Wie rund 5000 Zeilen kopierter Code entstanden, warum niemand den Moment bemerkte, an dem Duplikation teuer wurde — und was die Konsolidierung auf etwa ein Zehntel uns über DRY gelehrt hat.
Das ist doch schnell gemacht.
Ein Praxisbericht: Warum ein einzelner Satz zum verlässlichen Warnsignal wurde — und weshalb Batunet Projekte, die so beginnen, heute bewusst ablehnt. Über den Wert von Analyse und Architektur, die man nicht überspringen kann.
Wenn man einmal anfängt zu kopieren.
Ein Praxisbericht über die Eigendynamik des Kopierens: Wie aus einer vertretbaren ersten Kopie rund 5000 Zeilen fast gleichen Codes wurden, warum die gefährliche Entscheidung nicht die erste Kopie war, sondern die fehlende beim zweiten Mal — und was die Konsolidierung auf etwa ein Zehntel uns über den richtigen Zeitpunkt gelehrt hat.
Realtime ohne Neubau
Ein Praxisbericht: Ein über Jahre gewachsenes System sollte plötzlich in Echtzeit aktualisieren — eine Anforderung, für die seine Architektur nie gedacht war. Warum die Antwort kein Neubau war, sondern der gezielte Umbau eines einzigen Datenflusses. Über den Unterschied zwischen einer lokalen Anforderung und einem globalen Umbau.
Früh die Richtung ändern
Ein Praxisbericht: Der Plan war, ein bestehendes System zu erweitern. Während der Arbeit wurde sichtbar, dass jede weitere Funktion die Komplexität steigern würde. Statt am Plan festzuhalten, wurde die Richtung geändert und Funktionen in eigenständige APIs herausgelöst. Über die Kosten, einen überholten Plan zu verteidigen.
Der Prototyp, der kein Produkt war
Ein Praxisbericht: Ein Kunde wollte nur einen Machbarkeitsnachweis. Es entstand eine benutzbare Oberfläche. Danach wurde das Vorhaben eingestellt. Über den Unterschied zwischen einer Machbarkeitsstudie und einer Produktentwicklung — und warum man ihn von Anfang an benennen muss.
Software wird nie fertig
Ein Praxisbericht aus dem am längsten laufenden Kundenprojekt: Anforderungen ändern sich fortlaufend, Software wird nie fertig — und die einzige belastbare Antwort darauf ist eine Architektur, die Veränderung billig macht. Über das Loslassen der Vorstellung eines Endzustands.
Komplexität entfernen statt hinzufügen
Ein Praxisbericht: Externe API-Bausteine steckten eingebettet im Monolithen. Sie wurden herausgelöst und zu eigenständigen APIs gemacht — mit dem Ergebnis einer klareren Architektur und unabhängiger Skalierung. Warum Wegnehmen oft mehr wert ist als Hinzufügen.
Die Beiträge dieser Kategorie erscheinen fortlaufend. Grundbegriffe finden Sie schon heute im Glossar.
Zum GlossarVerwandte Themen.
Leitfäden, Entscheidungen, Leistungen und Arbeiten, die mit dieser Seite zusammenhängen.
Leistungen
Architekturentscheidungen
Ein konkretes Problem in diesem Feld?
Wir lösen es nicht nur auf dem Papier. Sprechen Sie mit den Ingenieuren, die es bauen würden.
