Ein zugänglicher Blick auf Rich Hickeys Clojure-Ideen: Einfachheit, Unveränderlichkeit und bessere Voreinstellungen — praktische Lektionen, um komplexe Systeme ruhiger und sicherer zu bauen.
Software wird selten auf einmal kompliziert. Sie erreicht das Ziel durch eine Reihe „vernünftiger“ Entscheidungen: ein schneller Cache, um eine Deadline zu schaffen, ein geteiltes veränderliches Objekt, um Kopien zu vermeiden, eine Ausnahme von der Regel, weil „dieses hier besonders ist“. Jede Entscheidung wirkt klein, aber zusammen entsteht ein System, in dem Änderungen riskant wirken, Bugs schwer zu reproduzieren sind und neue Features länger dauern als ihre Implementierung.
Komplexität gewinnt, weil sie kurzfristigen Komfort bietet. Es ist oft schneller, eine neue Abhängigkeit einzubauen, als eine bestehende zu vereinfachen. Es ist einfacher, State zu patchen, als zu fragen, warum State über fünf Services verteilt ist. Und wenn das System schneller wächst als die Dokumentation, ist es verlockend, sich auf Konventionen und tribal knowledge zu verlassen.
Dies ist kein Clojure-Tutorial, und du musst Clojure nicht kennen, um daraus Nutzen zu ziehen. Das Ziel ist, ein Paket praktischer Ideen zu entleihen, die oft mit Rich Hickeys Arbeit verbunden sind — Ideen, die du auf alltägliche Engineering-Entscheidungen anwenden kannst, unabhängig von Sprache.
Die meiste Komplexität entsteht nicht durch den bewusst geschriebenen Code, sondern durch das, was deine Tools standardmäßig einfach machen. Wenn der Default „mutable Objekte überall“ ist, endest du mit versteckter Kopplung. Wenn der Default „State lebt im Speicher“ ist, kämpfst du mit Debugging und Nachvollziehbarkeit. Defaults formen Gewohnheiten, und Gewohnheiten formen Systeme.
Wir konzentrieren uns auf drei Themen:
Diese Ideen entfernen nicht die Komplexität aus der Domäne, aber sie können verhindern, dass deine Software sie multipliziert.
Rich Hickey ist ein langjähriger Softwareentwickler und Designer, bekannt für die Schaffung von Clojure und für Vorträge, die gängige Programmiergewohnheiten infrage stellen. Sein Fokus ist nicht Trendjagd — es sind die wiederkehrenden Ursachen, warum Systeme schwer zu ändern, schwer zu durchdenken und schwer zu vertrauen sind, sobald sie wachsen.
Clojure ist eine moderne Programmiersprache, die auf bekannten Plattformen wie der JVM (Javas Laufzeit) und JavaScript läuft. Sie ist so entworfen, dass sie mit bestehenden Ökosystemen arbeitet und dabei einen bestimmten Stil fördert: Informationen als plain data repräsentieren, unveränderliche Werte bevorzugen und „was passiert ist" getrennt halten von „was du auf dem Bildschirm zeigst".
Man kann sie als eine Sprache sehen, die dich zu klareren Bausteinen anstößt und weg von versteckten Seiteneffekten.
Clojure wurde nicht geschaffen, um kleine Skripte kürzer zu machen. Ziel war wiederkehrender Projekt-Schmerz:
Clojures Defaults schieben in Richtung weniger beweglicher Teile: stabile Datenstrukturen, explizite Updates und Werkzeuge, die Koordination sicherer machen.
Der Wert ist nicht auf einen Sprachwechsel beschränkt. Hickeys Kernideen — vereinfachen durch Entfernen unnötiger Interdependenzen, Daten als dauerhafte Fakten behandeln und mutablen State minimieren — können Systeme in Java, Python, JavaScript und darüber hinaus verbessern.
Rich Hickey zieht eine scharfe Linie zwischen einfach und leicht — und das ist eine Grenze, die die meisten Projekte unbeachtet überschreiten.
Leicht betrifft, wie sich etwas jetzt anfühlt. Einfach betrifft, wie viele Teile es hat und wie eng sie verflochten sind.
In der Software bedeutet „leicht“ oft „heute schnell zu tippen“, während „einfach“ heißt „nächsten Monat schwerer kaputt zu machen".
Teams wählen häufig Abkürzungen, die kurzfristige Reibung reduzieren, aber unsichtbare Struktur hinzufügen, die gewartet werden muss:
Jede Wahl fühlt sich wie Geschwindigkeit an, erhöht aber die Zahl der beweglichen Teile, Sonderfälle und Querkopplungen. So werden Systeme fragil, ohne einen einzelnen dramatischen Fehler.
Schnelles Ausliefern kann großartig sein — aber Geschwindigkeit ohne Vereinfachung bedeutet in der Regel, dass du gegen die Zukunft leihst. Die Zinsen zeigen sich als schwer reproduzierbare Bugs, schleppendes Onboarding und Änderungen, die „vorsichtige Koordination" brauchen.
Stelle diese Fragen beim Review eines Designs oder PR:
„State“ ist einfach das Zeug in deinem System, das sich ändern kann: ein Warenkorb, ein Kontostand, die aktuelle Konfiguration, welcher Schritt ein Workflow hat. Das Schwierige ist nicht, dass sich Dinge ändern — es ist, dass jede Änderung eine neue Möglichkeit schafft, dass Dinge auseinanderlaufen.
Wenn Leute sagen „State verursacht Bugs“, meinen sie meist das: Wenn dieselbe Information zu verschiedenen Zeiten (oder an verschiedenen Orten) unterschiedlich sein kann, dann muss dein Code ständig die Frage beantworten: „Welche Version ist gerade die wahre?“ Diese Antwort falsch zu geben erzeugt Fehler, die zufällig erscheinen.
Mutabilität bedeutet, ein Objekt wird an Ort und Stelle bearbeitet: das „gleiche“ Ding wird mit der Zeit anders. Das klingt effizient, macht aber das Nachvollziehen schwerer, weil du nicht mehr auf das vertrauen kannst, was du vor einem Moment gesehen hast.
Ein nachvollziehbares Beispiel ist ein geteiltes Spreadsheet oder Dokument. Wenn mehrere Personen dieselben Zellen gleichzeitig bearbeiten können, kann dein Verständnis sofort ungültig werden: Summen ändern sich, Formeln brechen, oder eine Zeile verschwindet, weil jemand umgeordnet hat. Selbst wenn niemand böswillig ist, schafft die gemeinsame, editierbare Natur die Verwirrung.
Software-State verhält sich genauso. Wenn zwei Teile eines Systems denselben veränderlichen Wert lesen, kann ein Teil ihn still ändern, während der andere mit einer veralteten Annahme weiterarbeitet.
Mutabler State macht Debugging zur Archäologie. Ein Bug-Report sagt selten: „Die Daten wurden um 10:14:03 falsch geändert.“ Du siehst nur das Endergebnis: eine falsche Zahl, einen unerwarteten Status, eine Anfrage, die nur manchmal fehlschlägt.
Weil sich State über die Zeit ändert, wird die wichtigste Frage: Welche Abfolge von Änderungen führte hierher? Wenn du diese Historie nicht rekonstruieren kannst, wird das Verhalten unvorhersehbar:
Deshalb behandelt Hickey State als Komplexitätsmultiplikator: Sobald Daten gemeinsam und veränderlich sind, wächst die Zahl möglicher Interaktionen schneller als deine Fähigkeit, sie zu überblicken.
Unveränderlichkeit bedeutet einfach: Daten ändern sich nach ihrer Erzeugung nicht. Statt eine bestehende Information an Ort und Stelle zu bearbeiten, erzeugst du ein neues Stück Information, das die Aktualisierung widerspiegelt.
Denk an einen Kassenbon: Einmal gedruckt, wischt du keine Zeilen weg und rechnest nicht neu. Wenn sich etwas ändert, stellst du einen korrigierten Beleg aus. Der alte bleibt bestehen, und der neue ist klar „die neueste Version".
Wenn Daten nicht still verändert werden können, musst du dich nicht um unsichtbare Änderungen im Hintergrund sorgen. Das erleichtert das alltägliche Denken:
Das ist ein großer Teil dessen, warum Hickey über Einfachheit spricht: weniger versteckte Seiteneffekte bedeuten weniger mentale Verzweigungen, die man verfolgen muss.
Neue Versionen zu erzeugen kann verschwenderisch klingen, bis du die Alternative vergleichst. In-place Editieren lässt dich fragen: „Wer hat das geändert? Wann? Wie war es vorher?“ Mit unveränderlichen Daten sind Änderungen explizit: Eine neue Version existiert, und die alte bleibt für Debugging, Audit oder Rollback verfügbar.
Clojure fördert dies, indem es Updates als natürliche Erzeugung neuer Werte statt als Mutation alter Werte handhabbar macht.
Unveränderlichkeit ist nicht kostenlos. Du kannst mehr Objekte anlegen, und Teams, die an „einfach updaten“ gewöhnt sind, brauchen Zeit zur Anpassung. Die gute Nachricht: Moderne Implementierungen teilen oft Strukturen unter der Haube, um Speicherkosten zu reduzieren, und die Rendite ist typischerweise ruhigere Systeme mit weniger schwer erklärbaren Vorfällen.
Nebenläufigkeit ist einfach „viele Dinge passieren gleichzeitig“. Eine Web-App, die tausende Requests bedient, ein Zahlungssystem, das Salden aktualisiert und Belege erstellt, oder eine Mobile-App, die im Hintergrund syncet — all das ist nebenläufig.
Das Schwierige ist nicht, dass viele Dinge passieren. Es ist, dass sie oft dieselben Daten berühren.
Wenn zwei Worker denselben Wert lesen und dann modifizieren, kann das Endergebnis vom Timing abhängen. Das ist eine Race-Condition: kein leicht reproduzierbarer Fehler, sondern einer, der bei hoher Last auftritt.
Beispiel: zwei Requests aktualisieren ein Bestelltotal.
Nichts ist abgestürzt, aber ein Update ging verloren. Unter Last werden diese Timing-Fenster häufiger.
Traditionelle Fixes — Locks, synchronized-Blöcke, sorgfältige Reihenfolge — funktionieren, aber sie zwingen alle zur Koordination. Koordination ist teuer: Sie verlangsamt Durchsatz und wird fragil, wenn die Codebasis wächst.
Bei unveränderlichen Daten wird ein Wert nicht an Ort und Stelle editiert. Stattdessen erzeugst du einen neuen Wert, der die Änderung repräsentiert.
Dieser einzelne Wechsel beseitigt eine ganze Kategorie von Problemen:
Unveränderlichkeit macht Nebenläufigkeit nicht kostenlos — du brauchst immer noch Regeln dafür, welche Version aktuell ist. Aber sie macht nebenläufige Programme deutlich vorhersehbarer, weil die Daten selbst kein bewegliches Ziel mehr sind. Wenn der Traffic hochgeht oder Background-Jobs sich stapeln, siehst du seltener mysteriöse, timing-abhängige Fehler.
„Bessere Voreinstellungen" heißt, die sicherere Wahl passiert automatisch, und du nimmst extra Risiko nur, wenn du dich ausdrücklich dagegen entscheidest.
Das klingt klein, aber Defaults prägen, was Menschen an einem Montagmorgen schreiben, was Reviewer an einem Freitagnachmittag akzeptieren und was ein neuer Kollege aus dem erstbesten Codebase lernt.
Ein „besserer Default“ bedeutet nicht, dir jede Entscheidung abzunehmen. Es geht darum, den üblichen Pfad weniger fehleranfällig zu machen.
Zum Beispiel:
Keines davon eliminiert Komplexität, aber sie hindern sie daran, sich zu verbreiten.
Teams folgen nicht nur Dokumentation — sie folgen dem, „was der Code dich tun lässt".
Wenn das Mutieren geteilten States einfach ist, wird es zur normalen Abkürzung, und Reviewer diskutieren über Intent: „Ist das hier sicher?“ Wenn Unveränderlichkeit und pure Funktionen Default sind, können Reviewer sich auf Logik und Korrektheit konzentrieren, weil riskante Moves sofort auffallen.
Mit anderen Worten: Bessere Defaults schaffen eine gesündere Basislinie: die meisten Änderungen sehen konsistent aus, und ungewöhnliche Muster sind offensichtlich genug, um hinterfragt zu werden.
Langfristige Wartung dreht sich größtenteils darum, bestehenden Code sicher zu lesen und zu ändern.
Bessere Defaults helfen neuen Kolleg:innen beim Ramp-up, weil es weniger versteckte Regeln gibt („Vorsicht, diese Funktion ändert heimlich diese globale Map“). Das System wird leichter verständlich, was die Kosten für künftige Features, Fixes und Refactorings senkt.
Ein hilfreicher gedanklicher Shift in Hickeys Vorträgen ist, Fakten (was passiert ist) von Ansichten (was wir aktuell für wahr halten) zu trennen. Die meisten Systeme verwischen das, weil sie nur den neuesten Wert speichern — sie überschreiben gestern mit heute — und damit verschwindet die Zeit.
Eine Fakt ist ein unveränderlicher Eintrag: „Bestellung #4821 wurde um 10:14 aufgegeben“, „Zahlung erfolgreich“, „Adresse wurde geändert“. Diese werden nicht editiert; du fügst neue Fakten hinzu, wenn sich die Realität ändert.
Eine Ansicht ist, was deine App gerade braucht: „Was ist die aktuelle Versandadresse?“ oder „Wie hoch ist das aktuelle Kundenkonto?“ Ansichten können aus Fakten neu berechnet, gecacht, indexiert oder materialisiert werden, um schnell zu sein.
Wenn du Fakten behältst, gewinnst du:
Überschreiben ist wie das Aktualisieren einer Tabellenzelle: Du siehst nur die neueste Zahl.
Ein append-only Log ist wie ein Scheckbuchregister: Jede Buchung ist ein Fakt, und der „aktuelle Saldo“ ist eine Sicht, die aus den Einträgen berechnet wird.
Du musst keine komplette Event-Sourcing-Architektur einführen, um zu profitieren. Viele Teams starten kleiner: eine append-only Audit-Tabelle für kritische Änderungen, unveränderliche „Change Events“ für ein paar risikoreiche Workflows oder Snapshots plus ein kurzes History-Window. Wichtig ist die Gewohnheit: Fakten als dauerhaft behandeln und den aktuellen Zustand als praktische Projektion.
Eine von Hickeys praktischsten Ideen ist data first: Behandle die Informationen deines Systems als plain Werte (Fakten) und betrachte Verhalten als etwas, das gegen diese Werte ausgeführt wird.
Daten sind dauerhaft. Wenn du klare, selbstständige Informationen speicherst, kannst du sie später neu interpretieren, zwischen Services verschieben, reindexieren, auditieren oder in neue Features einspeisen. Verhalten ist weniger dauerhaft — Code ändert sich, Annahmen ändern sich, Abhängigkeiten ändern sich.
Wenn du beides vermischst, werden Systeme klebrig: Du kannst Daten nicht wiederverwenden, ohne das Verhalten, das sie erzeugte, mitzuziehen.
Fakten von Aktionen zu trennen verringert Kopplung, weil Komponenten sich auf eine Datenform einigen können, ohne denselben Codepfad zu teilen.
Ein Reporting-Job, ein Support-Tool und ein Billing-Service können dieselben Bestelldaten konsumieren und jeweils eigene Logik anwenden. Wenn du Logik in der gespeicherten Repräsentation einbettest, werden alle Konsumenten abhängig von dieser Logik — und Änderungen werden riskant.
Saubere Daten (leicht weiterzuentwickeln):
{
"type": "discount",
"code": "WELCOME10",
"percent": 10,
"valid_until": "2026-01-31"
}
Mini‑Programme in der Speicherung (schwer weiterzuentwickeln):
{
"type": "discount",
"rule": "if (customer.orders == 0) return total * 0.9; else return total;"
}
Die zweite Version wirkt flexibel, schiebt aber Komplexität in die Datenebene: Du brauchst einen sicheren Evaluator, Versionierungsregeln, Security-Grenzen, Debugging-Tools und einen Migrationsplan, wenn sich die Regel-Sprache ändert.
Wenn gespeicherte Informationen einfach und explizit bleiben, kannst du Verhalten über die Zeit ändern, ohne die Historie umzuschreiben. Alte Datensätze bleiben lesbar. Neue Services lassen sich hinzufügen, ohne die „Bedeutung“ der Daten neu zu erfinden. Und du kannst neue Interpretationen einführen — neue UI-Ansichten, Preisstrategien, Analytics — indem du neuen Code schreibst, nicht indem du die Bedeutung existierender Daten mutierst.
Die meisten Enterprise-Systeme scheitern nicht, weil ein Modul „schlecht“ ist. Sie scheitern, weil alles mit allem verbunden ist.
Enge Kopplung zeigt sich als „kleine" Änderungen, die Wochen Testaufwand auslösen. Ein Feld, das zu einem Service hinzugefügt wird, bricht drei Downstream-Consumer. Ein geteiltes DB-Schema wird zum Koordinationsengpass. Ein einzelner mutabler Cache oder ein Singleton-Config-Objekt wird heimlich zur Abhängigkeit der Hälfte des Codebases.
Kaskadierende Änderungen sind die natürliche Folge: Wenn viele Teile dasselbe veränderliche Ding teilen, wächst der Blast-Radius. Teams reagieren, indem sie Prozess, Regeln und Handoffs hinzufügen — und machen die Lieferung oft noch langsamer.
Du kannst Hickeys Ideen anwenden, ohne Sprachen zu wechseln oder alles neu zu schreiben:
Wenn Daten nicht unter deinen Füßen verschwinden, verbringst du weniger Zeit damit, zu debuggen „Wie kam es in diesen Zustand?“ und mehr Zeit damit, zu verstehen, was der Code tut.
Defaults sind der Ort, an dem Inkonsistenz einschleicht: Jedes Team erfindet sein eigenes Zeitformat, Error-Shape, Retry‑Policy und Nebenläufigkeitsmodell.
Bessere Defaults sehen so aus: versionierte Event-Schemas, standardisierte unveränderliche DTOs, klare Ownership von Writes und eine kleine Menge akzeptierter Bibliotheken für Serialisierung, Validierung und Tracing. Das Ergebnis sind weniger überraschende Integrationen und weniger Einzelfixes.
Beginne dort, wo sich ohnehin etwas ändert:
Diese Herangehensweise verbessert Zuverlässigkeit und Teamkoordination, während das System weiter läuft — und hält den Umfang klein genug, um abzuschließen.
Es ist einfacher, diese Ideen anzuwenden, wenn dein Workflow schnelles, risikoarmes Iterieren unterstützt. Wenn du z. B. neue Features in Koder.ai (eine chat-basierte Vibe‑Coding-Plattform für Web-, Backend- und Mobile-Apps) baust, entsprechen zwei Features direkt der „besseren Defaults"-Denkweise:
Auch wenn dein Stack React + Go + PostgreSQL (oder Flutter für Mobile) ist: Der Kernpunkt bleibt: Die Tools, die du täglich benutzt, lehren stillschweigend eine Arbeitsweise. Werkzeuge, die Nachvollziehbarkeit, Rollback und explizite Planung zur Routine machen, reduzieren den Druck, „mal schnell zu patchen".
Einfachheit und Unveränderlichkeit sind kraftvolle Defaults, keine moralischen Regeln. Sie reduzieren die Anzahl der Dinge, die unerwartet ändern können, was hilft, wenn Systeme wachsen. Aber reale Projekte haben Budget, Deadlines und Beschränkungen — und manchmal ist Mutabilität das richtige Werkzeug.
Mutabilität kann praktisch sein in Performance-Hotspots (enge Schleifen, High-Throughput-Parsing, Grafik, numerische Arbeit), wo Allokationen dominieren. Sie kann auch in kontrolliertem Scope okay sein: lokale Variablen, ein privater Cache hinter einer Schnittstelle oder eine Single-Threaded-Komponente mit klaren Grenzen.
Der Schlüssel ist Eindämmung. Wenn das „mutable Ding“ nie ausläuft, kann es die Komplexität der Codebasis nicht verbreiten.
Selbst in einem überwiegend funktionalen Stil brauchen Teams klare Ownership:
Das ist der Punkt, an dem Clojures Bias zu Daten und expliziten Grenzen hilft — aber die Disziplin ist architektonisch, nicht sprachspezifisch.
Keine Sprache behebt schlechte Anforderungen, ein unklar modelliertes Domänenmodell oder ein Team, das sich nicht auf „done“ einigen kann. Unveränderlichkeit macht einen verworrenen Workflow nicht verständlich, und „funktionaler" Code kann immer noch die falschen Geschäftsregeln schön verpacken.
Wenn dein System bereits in Produktion ist, behandle diese Ideen nicht als Alles-oder-Nichts-Rewrite. Suche die kleinste Veränderung, die das Risiko senkt:
Das Ziel ist keine Reinheit — es sind weniger Überraschungen pro Änderung.
Das ist eine Sprint-große Checkliste, die du anwenden kannst, ohne Sprachen, Frameworks oder Teamstruktur zu ändern.
Macht eure „Datenformen" standardmäßig unveränderlich. Behandle Request/Response-Objekte, Events und Nachrichten als Werte, die einmal erstellt und nie modifiziert werden. Wenn etwas geändert werden muss, erstelle eine neue Version.
Bevorzugt pure Funktionen in Workflow-Kernen. Wähle einen Workflow (z. B. Pricing, Permissions, Checkout) und refaktoriere den Kern in Funktionen, die Daten rein entgegennehmen und zurückgeben — ohne versteckte Lese/Schreib-Operationen.
Verschiebt State an weniger, klarere Orte. Wählt eine Quelle der Wahrheit pro Konzept (Kundenstatus, Feature-Flags, Inventar). Wenn mehrere Module eigene Kopien halten, macht das zur expliziten Entscheidung mit einer Sync-Strategie.
Fügt ein append-only Log für Schlüssel-Fakten hinzu. Für einen Domänenbereich, zeichnet „was passiert ist“ als dauerhafte Events auf (auch wenn ihr weiterhin den aktuellen Zustand speichert). Das verbessert Nachvollziehbarkeit und reduziert Ratespiele.
Definiert sichere Defaults in APIs. Defaults sollten überraschendes Verhalten minimieren: explizite Zeitzonen, explizite Null-Handhabung, explizite Retries und explizite Ordnungs-Garantien.
Suche nach Material zu Einfachheit vs. Leichtigkeit, State-Management, wertorientiertem Design, Unveränderlichkeit und wie „Historie" (Fakten über Zeit) Debugging und Betrieb erleichtert.
Einfachheit ist kein Feature, das du draufpackst — es ist eine Strategie, die du in kleinen, wiederholbaren Entscheidungen praktizierst.
Komplexität baut sich durch kleine, lokal nachvollziehbare Entscheidungen auf (zusätzliche Flags, Caches, Ausnahmen, geteilte Helfer), die Betriebsmodi und Kopplung hinzufügen.
Ein gutes Signal ist, wenn eine „kleine Änderung“ koordinierte Anpassungen in mehreren Modulen oder Services erfordert oder Reviewer auf tribal knowledge angewiesen sind, um die Sicherheit zu beurteilen.
Weil Abkürzungen die Reibung für heute optimieren (Schneller zum Deploy), aber Kosten in die Zukunft verschieben: mehr Debugging, Koordinationsaufwand und Änderungsrisiko.
Eine nützliche Gewohnheit in Design-/PR-Reviews ist zu fragen: „Welche neuen beweglichen Teile oder Sonderfälle führt das ein, und wer wird sie pflegen?“
Voreinstellungen prägen das Verhalten von Entwickler:innen unter Druck. Wenn Mutation Standard ist, verbreitet sich geteilter Zustand. Wenn „im Speicher ist okay“ die Default-Annäherung ist, geht Nachvollziehbarkeit verloren.
Verbessere Defaults, indem der sichere Weg der Weg des geringsten Widerstands ist: unveränderliche Daten an Grenzen, explizite Zeitzonen/Nullwerte/Retry-Regeln und klare Besitzverhältnisse für State.
State ist alles, was sich über die Zeit ändert. Das Schwierige ist, dass jede Änderung Möglichkeiten für Uneinigkeit schafft: Zwei Komponenten können unterschiedliche „aktuelle“ Werte haben.
Bugs erscheinen als timing-abhängiges Verhalten („läuft lokal“, flaky in Production), weil die Frage wird: Auf welche Version der Daten haben wir gehandelt?
Unveränderlichkeit heißt praktisch: Du änderst einen Wert nicht an Ort und Stelle; stattdessen erzeugst du einen neuen Wert, der die Aktualisierung widerspiegelt.
Praxisnutzen:
Mutabilität ist akzeptabel, wenn sie eingeschlossen ist:
Regel: Lass mutable Strukturen nicht über Grenzen hinweg „auslaufen“, wo viele Teile lesen und schreiben können.
Race-Conditions entstehen typischerweise, weil mehrere Arbeiter dieselben, veränderlichen Daten lesen und dann schreiben.
Unveränderlichkeit reduziert die Koordinationsfläche, weil Schreiber neue Versionen erzeugen statt ein geteiltes Objekt zu editieren. Du brauchst weiterhin eine Regel, wie die „aktuelle“ Version veröffentlicht wird, aber die Daten selbst sind kein bewegliches Ziel mehr.
Betrachte Fakten als append-only Aufzeichnungen dessen, was passiert ist (Events), und den „aktuellen Zustand“ als davon abgeleitete Sicht.
Inkrementelle Schritte ohne vollständiges Event-Sourcing:
Speichere Informationen als klare, explizite Daten (Werte) und wende Verhalten gegen sie an. Vermeide ausführbaren Code in gespeicherten Datensätzen.
Vorteile:
Wähle einen Workflow mit hoher Änderungsfrequenz und mache drei Dinge:
Erfolg misst sich an weniger flakigen Bugs, kleinerer Blast-Radius pro Änderung und weniger „vorsichtiger Koordination“ bei Releases.