Die Wissensbasis von Batunet.
Keine Blogbeiträge, sondern belastbare Antworten auf konkrete Engineering-Fragen. Eine Frage, eine Seite, eine Antwort.
Eine statische Karte des Entity-Graphen: jede Entität ein Knoten, jede Beziehung eine Kante, die Cluster nach Art gruppiert.
Wissensgraph →Die gesamte Wissensbasis, auf einen Griff.
Suchen Sie nach Thema, oder filtern Sie nach Inhaltstyp und Kategorie.
Inhaltstyp
Kategorie
60 Ergebnisse
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.
Datenmodellierung, die Bestand hat
Das Datenmodell überdauert Framework, Oberfläche und Datenbank: Warum man die Domäne modelliert, für Veränderung baut und ein falsches Modell so teuer ist.
KI in Produktionssystemen — Engineering statt Demo
Der weite Weg von der KI-Demo zum verlässlichen Produktivsystem: Evaluation, Fehlermodi, Guardrails — das Wahrscheinliche hinter Deterministischem einfassen.
Für den Fehlerfall entwerfen
Ein System, dessen Fehlermodi unbekannt sind, ist nicht fertig: Fehler eindämmen statt verhindern, sicher wiederholen, würdevoll abbauen, den Fehlerfall proben.
Sicherheit als Architektureigenschaft
Sicherheit ist keine Funktion, die man anbaut, sondern eine Eigenschaft im Entwurf: Bedrohungsmodellierung, geringste Rechte, Tiefenverteidigung, sichere Defaults.
Symfony für langlebige Enterprise-Systeme
Warum Symfonys Explizitheit, Komponenten und Stabilitätskultur langlebige Enterprise-Systeme tragen — und wo Laravel die passendere Wahl bleibt.
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.
Wann KI die falsche Lösung ist
Von einem Unternehmen, das KI baut: wann sie die falsche Wahl ist. Welche Form ein Problem braucht, warum eine Regel oft überlegen ist, was KI am Ort kostet.
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.
Verlässliche KI-Antworten — Architektur für Kontext und Quellen
Wie man eine KI-Antwort in verlässlichem, aktuellem Kontext und nachvollziehbaren Quellen gründet, sodass sie stimmt und belegbar ist — nicht nur flüssig.
PostgreSQL oder MySQL für langlebige Systeme
Beide Datenbanken sind reif und tragen ein System über Jahre. Was sie teilen, wo sie sich unterscheiden — entschieden an der Form der Daten und am Team, nicht am Ranking.
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.
Laravel für Enterprise-Systeme
Wann Laravel für langlebige, geschäftskritische Systeme die richtige Wahl ist — und wann nicht: Architektur, Wartbarkeit, Skalierungsrealität, Betrieb, Team.
Laravel-Upgrades für langlebige Systeme
Wie man ein Laravel-System über Jahre aktuell hält, ohne Angst vor dem Sprung: aufgeschobene Upgrades als Gefahr, kontinuierlich statt sprunghaft, Tests als Netz.
Idempotenz in verteilten Systemen
Warum verteilte Systeme doppelte Nachrichten ertragen müssen und wie man sie idempotent macht: Idempotency Keys, Retries, Outbox und Inbox.
API Design für langlebige Systeme
Wie man APIs entwirft, die Jahre überdauern, ohne die Systeme ihrer Nutzer zu brechen: Verträge, Kompatibilität, Versionierung, Fehler, Evolution.
REST, GraphQL oder RPC — die Wahl des API-Stils
Die Wahl des API-Stils nach Passung statt Mode: Was REST, GraphQL und RPC unterscheiden, welche Problemform zu welchem Stil passt, was jeder kostet.
API-Versionierung ohne Kunden zu brechen
Wie man eine API über Jahre weiterentwickelt, ohne die Systeme der Kunden zu brechen: kompatibel erweitern, sauber versionieren, Deprecation als Prozess.
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.
Agentic Coding — wenn Softwareentwicklung zur Orchestrierung wird
Agentic Coding verschiebt den Engpass der Softwareentwicklung: vom Schreiben des Codes zum Definieren, Prüfen und Verantworten der Arbeit.
Wann sich Tests wirklich lohnen
Testen als Investition mit unterschiedlicher Rendite: Wo Tests Wert schaffen, wo sie mehr Pflege als Nutzen erzeugen. Ohne Abdeckungs-Dogma.
Observability ist Architektur
Warum ein System, das sein Verhalten nicht erklären kann, nicht sicher betrieben werden kann — Beobachtbarkeit als Architektureigenschaft, nicht Werkzeug.
Zero-Downtime-Datenbankmigrationen
Wie man produktive Datenbanken ohne Stillstand weiterentwickelt: Expand/Contract, rückwärtskompatible Schema-Evolution, Deploy-Sequenz, Backfills, Rollback.
Caching ist kein Performance-Feature
Caching ist keine Optimierung, sondern eine Architekturentscheidung — Latenz gegen Konsistenz. Was man nie cacht, Invalidierung, Schichten, Fehlermodi.
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.
Eine Migration ist ein Vertrauensproblem
Ein Praxisbericht: Eine große Infrastruktur-Migration über mehrere Server, Datenbanken, Backups und einen Anbieterwechsel. Die eigentliche Schwierigkeit war nicht technisch, sondern die Gewissheit, nichts vergessen zu haben. Über Migrationen als Vertrauensprobleme — und wie man Vertrauen herstellt statt es zu hoffen.
Schnittstellen überdauern Implementierungen
Ein Praxisbericht: Ein externer API-Anbieter wurde ersetzt. Millionen bestehender Datensätze, eine inkompatible neue Struktur — es folgten Abbildung, Migration, Prüfung. Warum die Schnittstelle das Beständige war und die Implementierung dahinter das Vergängliche.
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.
Als Schema und Modell auseinanderliefen
Ein Praxisbericht: In einem großen Projekt mit mehreren Teams hielt sich ein Fehler hartnäckig. Die Ursache war klein — das Datenbankschema hatte sich geändert, die ORM-Abbildung nicht. Warum winzige Unstimmigkeiten zwischen Datenbank und Modell unverhältnismäßig große Probleme erzeugen.
Gute Werkzeuge verstärken
Ein Praxisbericht: KI wurde in den Engineering-Alltag integriert — erwartet als kleiner Helfer, erlebt als grundlegende Verbesserung der Produktivität. Ohne Aufregung betrachtet: Warum gute Werkzeuge Ingenieure verstärken, statt sie zu ersetzen — und warum das den Wert von Urteilskraft erhöht, nicht senkt.
Die beste Architektur entfernt Komponenten
Ein Praxisbericht: Hunderte zwischengeschaltete API-Server wurden durch eine Proxy-Architektur ersetzt. Die Infrastruktur wurde einfacher, nicht mächtiger. Warum die beste Architektur oft Komponenten entfernt, statt neue hinzuzufügen.
Warum wir meist mit einem modularen Monolithen beginnen
Für die meisten Systeme ist ein modularer Monolith die günstigere Wahl — bis eine konkrete Grenze verteilte Dienste wirklich verlangt.
Warum vorzeitige Abstraktion Komplexität schafft
Abstraktionen sollten aus wiederholten, konkreten Fällen entstehen — nicht aus der Erwartung, dass sie einmal gebraucht werden.
Warum Observability zur Architektur gehört
Ob ein System beobachtbar ist, entscheidet sich beim Entwurf — nicht beim ersten Incident.
ADR-001: Modularer Monolith als Ausgangspunkt, Microservices auf Nachweis
Verteilte Systeme lösen reale Probleme — unabhängige Skalierung, unabhängiges Deployment — bringen aber Netzwerkgrenzen, eventual consistency und Betriebsaufwand mit. Wann rechtfertigt der Nutzen diese Kosten?
ADR-002: Queue statt synchroner Verarbeitung außerhalb des kritischen Pfads
Synchrone Nebenwirkungen koppeln die Antwortzeit an das langsamste beteiligte System und lassen einen Request scheitern, wenn eine Nebenwirkung scheitert. Asynchrone Verarbeitung entkoppelt, bringt aber eventual consistency und Zustellsemantik mit.
ADR-003: Normalisierte Tabellen vor JSONB in PostgreSQL
JSONB ist verlockend flexibel, verlagert aber Struktur und Integrität aus der Datenbank in den Anwendungscode. Normalisierte Tabellen erzwingen Struktur, sind aber weniger flexibel bei häufigen Schemaänderungen.
Einen Legacy-Monolithen modernisieren
Ein gewachsenes Altsystem ablösen, ohne den Betrieb zu riskieren — Schritt für Schritt statt Big-Bang.
Eine öffentliche API entwerfen
Eine API als langlebigen Vertrag entwerfen — versioniert, dokumentiert, stabil für ihre Nutzer.
Asynchrone Verarbeitung einführen
Nebenwirkungen aus dem kritischen Antwortpfad lösen — robust, nachvollziehbar, idempotent.
Laravel oder Symfony
Ein ehrlicher Architekturvergleich der beiden PHP-Frameworks — ohne Sieger, mit Kontext.
Idempotenz
Eine Operation, die mehrfach ausgeführt dasselbe Ergebnis liefert wie einmal.
OIDC (OpenID Connect)
Eine Identitätsschicht auf OAuth 2.0 für Authentifizierung und Single Sign-on.
Multi-Tenancy
Eine Software-Instanz bedient mehrere Kunden mit getrennten Daten.
Event Sourcing
Der Zustand wird als Folge unveränderlicher Ereignisse gespeichert, nicht als aktueller Wert.
DRY (Don't Repeat Yourself)
Jede Wissenseinheit soll genau eine maßgebliche Darstellung im System haben.
Cone of Uncertainty (Trichter der Unsicherheit)
Die Spanne einer Aufwandsschätzung ist am Anfang eines Vorhabens am größten und verengt sich erst mit wachsendem Verständnis.
Rule of Three (Regel der Drei)
Zwei Vorkommen können Zufall sein; beim dritten wird aus Ähnlichkeit ein Muster — und ein Zeitpunkt zum Zusammenführen.
Elf Felder. Ein Anspruch.
Jede Kategorie ist ein zusammenhängender Wissenscluster — von den Grundlagen bis zu den Entscheidungen, die Teams wirklich treffen.
Womit man anfängt.
Nach Bedeutung geordnet — die Grundlagen zuerst, dann das Aufbauende.
Sprechen wir über Ihr Vorhaben.
Beschreiben Sie kurz Ihr Vorhaben. Das erste Gespräch führen Sie direkt mit der Geschäftsführung.
