Reference Guides

Alle Leitfäden, geordnet.

Die belastbaren Reference Guides — automatisch aus der Wissensbasis generiert.

ArchitectureSoftware, die in zehn Jahren noch läuftWelche Engineering-Entscheidungen Software zehn Jahre tragfähig halten — Kopplung, Umkehrbarkeit, Betrieb, Standards. Mit Trade-offs statt Marketing.Fortgeschritten16 Min.ArchitectureReversibilität vor VorhersageMan kann die Zukunft nicht vorhersagen — also Änderung billig halten statt darauf zu wetten. Welche Entscheidungen man verlangsamt und umkehrbar baut.Vertiefung15 Min.ArchitectureBusiness-Logik gehört nicht in ControllerWarum Geschäftsregeln in eine framework-unabhängige Domänenschicht gehören, nicht in den Controller: Symptome, Wartungskosten, Testbarkeit, Migration.Fortgeschritten15 Min.DatabasesDatenmodellierung, die Bestand hatDas 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.Vertiefung16 Min.AIKI in Produktionssystemen — Engineering statt DemoDer weite Weg von der KI-Demo zum verlässlichen Produktivsystem: Evaluation, Fehlermodi, Guardrails — das Wahrscheinliche hinter Deterministischem einfassen.Vertiefung15 Min.DevOpsFür den Fehlerfall entwerfenEin System, dessen Fehlermodi unbekannt sind, ist nicht fertig: Fehler eindämmen statt verhindern, sicher wiederholen, würdevoll abbauen, den Fehlerfall proben.Vertiefung15 Min.SecuritySicherheit als ArchitektureigenschaftSicherheit ist keine Funktion, die man anbaut, sondern eine Eigenschaft im Entwurf: Bedrohungsmodellierung, geringste Rechte, Tiefenverteidigung, sichere Defaults.Vertiefung15 Min.SymfonySymfony für langlebige Enterprise-SystemeWarum Symfonys Explizitheit, Komponenten und Stabilitätskultur langlebige Enterprise-Systeme tragen — und wo Laravel die passendere Wahl bleibt.Vertiefung15 Min.ArchitectureAusgereifte Technik vor NeuheitTechnologiewahl ohne Mode: Warum Reife heißt, dass andere die Fehler schon fanden — was das Neue verbirgt, wann es trotzdem richtig ist. Kontext und Lebensdauer.Vertiefung15 Min.ArchitectureModularer Monolith vs. MicroservicesKein Glaubenskrieg, sondern eine Entscheidung über die Verteilung von Komplexität: Was ein modularer Monolith ist, wann Microservices objektiv besser sind.Vertiefung15 Min.AIWann KI die falsche Lösung istVon 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.Vertiefung15 Min.ArchitectureBuild, Buy oder Configure — wann Individualsoftware sich rechnetSelbst bauen, kaufen oder konfigurieren — ehrlich, auch wenn die Antwort 'kaufen' lautet. Das Kriterium: Differenzierung und Lebensdauer, verborgene Kosten.Grundlagen15 Min.AIVerlässliche KI-Antworten — Architektur für Kontext und QuellenWie man eine KI-Antwort in verlässlichem, aktuellem Kontext und nachvollziehbaren Quellen gründet, sodass sie stimmt und belegbar ist — nicht nur flüssig.Vertiefung15 Min.DatabasesPostgreSQL oder MySQL für langlebige SystemeBeide 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.Vertiefung15 Min.ArchitectureWarum Softwareprojekte wirklich scheiternSoftwareprojekte scheitern selten an Technologie, sondern weil Engineering-Entscheidungen unumkehrbar werden, bevor das Problem verstanden ist.Vertiefung15 Min.ArchitectureServerseitiges Rendering oder SPAServerseitig gerendert oder SPA — die Frontend-Wahl, die über die Zehn-Jahres-Wartbarkeit entscheidet. Nach Interaktivität und Lebensdauer, nicht nach Mode.Vertiefung15 Min.LaravelLaravel für Enterprise-SystemeWann Laravel für langlebige, geschäftskritische Systeme die richtige Wahl ist — und wann nicht: Architektur, Wartbarkeit, Skalierungsrealität, Betrieb, Team.Vertiefung16 Min.LaravelLaravel-Upgrades für langlebige SystemeWie man ein Laravel-System über Jahre aktuell hält, ohne Angst vor dem Sprung: aufgeschobene Upgrades als Gefahr, kontinuierlich statt sprunghaft, Tests als Netz.Vertiefung15 Min.APIsIdempotenz in verteilten SystemenWarum verteilte Systeme doppelte Nachrichten ertragen müssen und wie man sie idempotent macht: Idempotency Keys, Retries, Outbox und Inbox.Vertiefung14 Min.APIsAPI Design für langlebige SystemeWie man APIs entwirft, die Jahre überdauern, ohne die Systeme ihrer Nutzer zu brechen: Verträge, Kompatibilität, Versionierung, Fehler, Evolution.Vertiefung15 Min.APIsREST, GraphQL oder RPC — die Wahl des API-StilsDie Wahl des API-Stils nach Passung statt Mode: Was REST, GraphQL und RPC unterscheiden, welche Problemform zu welchem Stil passt, was jeder kostet.Vertiefung15 Min.APIsAPI-Versionierung ohne Kunden zu brechenWie man eine API über Jahre weiterentwickelt, ohne die Systeme der Kunden zu brechen: kompatibel erweitern, sauber versionieren, Deprecation als Prozess.Vertiefung13 Min.ArchitectureLegacy-Modernisierung ohne Big BangWie man ein Produktivsystem inkrementell und umkehrbar ablöst statt per Rewrite: Strangler Fig, Anti-Corruption Layer, Datenmigration, Parallelbetrieb.Vertiefung14 Min.ArchitectureEin Legacy-System übernehmen — die ersten 90 TageDie Übernahme eines Systems, das man nicht gebaut hat: zuerst verstehen statt ändern, Sicherheitsnetze vor dem ersten Eingriff, die Karte, das Verhalten festhalten.Vertiefung15 Min.ArchitectureWann ein Rewrite die falsche Entscheidung istWarum ein Rewrite eingebettetes Wissen verwirft und ein bewegliches Ziel jagt, wann ein Neubau doch richtig ist — und warum schrittweise fast immer besser ist.Vertiefung15 Min.AIAgentic Coding — wenn Softwareentwicklung zur Orchestrierung wirdAgentic Coding verschiebt den Engpass der Softwareentwicklung: vom Schreiben des Codes zum Definieren, Prüfen und Verantworten der Arbeit.Vertiefung18 Min.TestingWann sich Tests wirklich lohnenTesten als Investition mit unterschiedlicher Rendite: Wo Tests Wert schaffen, wo sie mehr Pflege als Nutzen erzeugen. Ohne Abdeckungs-Dogma.Fortgeschritten15 Min.DevOpsObservability ist ArchitekturWarum ein System, das sein Verhalten nicht erklären kann, nicht sicher betrieben werden kann — Beobachtbarkeit als Architektureigenschaft, nicht Werkzeug.Vertiefung15 Min.DatabasesZero-Downtime-DatenbankmigrationenWie man produktive Datenbanken ohne Stillstand weiterentwickelt: Expand/Contract, rückwärtskompatible Schema-Evolution, Deploy-Sequenz, Backfills, Rollback.Vertiefung14 Min.PerformanceCaching ist kein Performance-FeatureCaching ist keine Optimierung, sondern eine Architekturentscheidung — Latenz gegen Konsistenz. Was man nie cacht, Invalidierung, Schichten, Fehlermodi.Vertiefung18 Min.
Engineering Stories

Gelernte Lektionen.

Keine Leitfäden, sondern Fehler und was sie uns gelehrt haben — anonym, ohne Drama. Der Fehler ist der Lehrer.

Architecture5000 Zeilen Copy & PasteEine Engineering Story: 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.4 Min.ArchitectureDas ist doch schnell gemacht.Eine Engineering Story: 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.4 Min.ArchitectureWenn man einmal anfängt zu kopieren.Eine Engineering Story ü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.4 Min.ArchitectureRealtime ohne NeubauEine Engineering Story: 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.3 Min.ArchitectureFrüh die Richtung ändernEine Engineering Story: 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.3 Min.ArchitectureDer Prototyp, der kein Produkt warEine Engineering Story: 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.3 Min.CloudEine Migration ist ein VertrauensproblemEine Engineering Story: 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.4 Min.APIsSchnittstellen überdauern ImplementierungenEine Engineering Story: 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.4 Min.ArchitectureSoftware wird nie fertigEine Engineering Story 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.4 Min.ArchitectureKomplexität entfernen statt hinzufügenEine Engineering Story: 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.3 Min.DatabasesAls Schema und Modell auseinanderliefenEine Engineering Story: 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.4 Min.AIGute Werkzeuge verstärkenEine Engineering Story: 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.3 Min.CloudDie beste Architektur entfernt KomponentenEine Engineering Story: 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.3 Min.

Sprechen wir über Ihr Vorhaben.

Kein Vertrieb. Ein direktes Gespräch mit der Geschäftsführung.