Connect with us

Entwicklung & Code

UserDeleted, Diagnose Mord: Wenn Software wie ein Tatort klingt


Wenn ich Kunden zu Domain-Driven Design (DDD) und Event Sourcing berate, gibt es einen Moment, der regelmäßig eintritt. Das Team wirkt selbstbewusst, vielleicht sogar ein wenig stolz. Sie sagen mir:

Weiterlesen nach der Anzeige

„Eigentlich arbeiten wir schon mit Events.“

Und dann zeigen sie mir ihre Events:

  • UserCreated
  • OrderUpdated
  • InvoiceDeleted

Und innerlich zucke ich zusammen.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Denn das sind keine Events, sondern klassisches CRUD, nur eben mit Event-Syntax. Es hat die äußerliche Form von Events, aber keine innerliche Semantik. Und dieser Unterschied, so subtil er auch erscheinen mag, ist der Unterschied zwischen einem System, das die Sprache des Business spricht, und einem, das die Sprache von Datenbanken spricht.

Weiterlesen nach der Anzeige

Stellen wir uns einen Kunden vor, der sich mit Enterprise-Drucken beschäftigt. Die Software verwaltet Tausende von Druckern in großen Organisationen: in Krankenhäusern, Universitäten und Unternehmensbüros. Drucker müssen dem System hinzugefügt, für Wartungsarbeiten offline genommen, pausiert, fortgesetzt und schließlich entfernt werden, wenn sie außer Betrieb genommen werden.

Das Team hat etwas gebaut, das sie ein „Event-getriebenes System“ nennen. Und das sind ihre Events:

  • PrinterCreated
  • PrinterUpdated
  • PrinterDeleted

Das war’s. Drei Events. Kommt Ihnen das bekannt vor?

Das ist CRUD in Verkleidung. Die Namen haben sich von INSERT, UPDATE und DELETE zu Created, Updated und Deleted geändert, aber die semantische Armut ist dieselbe. Wenn man sich ein PrinterUpdated-Event ansieht, was weiß man dann? Irgendetwas hat sich geändert. Aber was genau hat sich geändert? Dazu muss man in den Payload schauen. Warum hat es sich geändert? Keine Ahnung. War es eine geplante Wartungsmaßnahme oder ein unerwarteter Ausfall? Das Event verrät es nicht.

Und mich erinnert das immer an ein etwas düsteres Beispiel (und die Ironie ist hoffentlich offensichtlich): Betrachten wir UserDeleted (was mir in der Praxis auch regelmäßig begegnet).

Sprechen Sie das mal laut und bewusst aus: UserDeleted. Es klingt, als hätte man die Nutzerin oder den Nutzer erfolgreich ermordet:

„Der Nutzer wurde eliminiert.“

Wäre das ein Krimi, würden die Ermittlerinnen und Ermittler sich jetzt Notizen machen.

Aber was wahrscheinlich gemeint war: AccountClosed. Oder UserDeactivated. Oder SubscriptionCancelled. Jedes davon hat eine andere Bedeutung, andere geschäftliche Implikationen, andere nachgelagerte Effekte. Aber CRUD-Sprache presst all diesen Reichtum in ein einziges, leicht morbides Verb.

Das ist nicht nur unpräzise. Es ist aktiv irreführend. CRUD-Sprache verliert nicht nur Information. Sie kann Events wie einen Polizeibericht klingen lassen.

Zurück zu unseren Druckern. Eine Wartungstechnikerin ruft beim Helpdesk an:

„Dieser Drucker im dritten Stock funktioniert nicht. Was ist passiert?“

Der Support-Mitarbeiter schaut auf den aktuellen Zustand in der Datenbank:

{ "printerId": "printer-3f-01",
"status": "offline"
}

Das ist alles, was er sieht. Der Drucker ist offline. Aber warum? Wann ging er offline? Wurde er manuell für Wartungsarbeiten offline genommen, oder ist er unerwartet ausgefallen? Ist das schon einmal passiert? Wie oft?

Mit CRUD-Events muss der Mitarbeiter nun Logs durchforsten, Zeitstempel korrelieren, vielleicht die Technikerin später zurückrufen. Jede Minute, die mit Nachforschungen verbracht wird, bedeutet verlorenes Geld und wachsende Frustration.

Das sind die versteckten Kosten semantischer Armut: Nicht nur verlorene Information, sondern verlorene Zeit, verlorener Kontext, verlorenes Vertrauen in das System.

Wie würden echte Events aussehen? Events, die erfassen, was tatsächlich passiert ist? In der Sprache der Domäne?

  • PrinterAdded
  • PrinterBecameOnline
  • PrinterPaused
  • PrinterResumed
  • PrinterWentOffline
  • PrinterRemoved

Beachten Sie die subtile, aber wichtige Verschiebung. Es heißt PrinterAdded, nicht PrinterCreated. Warum? Weil der Drucker in keinem sinnvollen Weg „erstellt“ wurde. Niemand hat einen Drucker hergestellt, indem eine Datenbankzeile eingefügt wurde. Der Drucker existierte bereits. Er war ein physisches Objekt, das in einem Karton lag, aus einer Fabrik geliefert. Was passiert ist: Er wurde dem System lediglich hinzugefügt.

Created ist CRUD-Sprache. Added ist Domänensprache. Der Unterschied zählt.

Genauso Removed statt Deleted: Der Drucker wurde nicht zerstört. Er steht wahrscheinlich irgendwo in einem Lagerraum und wartet darauf, neu zugewiesen zu werden. Er wurde aus der Verwaltung dieses Systems entfernt. Das ist passiert. Das sollte das Event sagen.

Spielen wir nun den Support-Anruf mit echten Events durch. Der Mitarbeiter ruft die Historie des Druckers auf:

2026-01-15 09:00 PrinterAdded
2026-01-15 09:05 PrinterBecameOnline
2026-01-16 14:30 PrinterPaused { "reason": "scheduled maintenance" }
2026-01-16 16:00 PrinterResumed
2026-01-17 11:45 PrinterWentOffline { "reason": "paper jam detected" }
2026-01-17 12:00 PrinterBecameOnline
2026-01-18 09:22 PrinterWentOffline { "reason": "connection lost" }

Jetzt kann er alles sehen:

  • Der Drucker ging heute um 09:22 Uhr offline, weil die Verbindung verloren ging.
  • Das ist das zweite unerwartete Offline-Event in zwei Tagen.
  • Gestern war es ein Papierstau, heute ist es Konnektivität.
  • Davor gab es eine geplante Wartungspause, die reibungslos verlief.

Die Technikerin muss in Konsequenz also nicht blind herumprobieren. Sie weiß, dass sie die Netzwerkverbindung prüfen muss, nicht das Papierfach. Sie kann ein Muster erkennen, weil das gleiche Problem in der Vergangenheit schon mit anderen Druckern aufgetreten ist: vielleicht versagt gerade die Netzwerkkarte dieses Druckers.

Das ist der Wert, den CRUD-Events nicht liefern können. Nicht nur „was ist der Zustand“, sondern „wie ist er dorthin gekommen“ und „was sagt uns dieses Muster“.

Das berührt etwas Grundlegenderes. In einem früheren Beitrag habe ich darüber geschrieben, wie niemand Geschichten mit CRUD erzählt. Man sagt nicht „Rotkäppchen wurde erstellt, dann aktualisiert, dann wurde die Großmutter gelöscht.“ Das ist absurd. Man erzählt die Geschichte durch Events: was passiert ist, in welcher Reihenfolge und warum es wichtig war.

Und in einem anderen Beitrag über DDD habe ich argumentiert, dass Domain-Driven Design unnötig kompliziert gemacht wurde. Die Essenz ist einfach: „Sprich die Sprache der Domäne!“ Aber wir haben diese Einfachheit unter Schichten von Patterns und Jargon begraben.

Hier ist der Zusammenhang: Wer gute Events formuliert, spricht automatisch die Sprache der Domäne. Man kann nicht PrinterPaused schreiben, ohne zu verstehen, dass Pausieren ein Konzept in dieser Domäne ist, unterschieden vom Offline-Gehen, unterschieden vom Entfernen. Der Akt des Benennens von Events zwingt dazu, Gespräche mit Domänenexpertinnen und -experten zu führen. „Wie nennen Sie es, wenn ein Drucker vorübergehend, aber absichtlich aufhört zu arbeiten?“ Diese Frage führt direkt ins Herz der Domäne.

Das ist DDD, ohne es DDD zu nennen. Keine Aggregates, keine Bounded-Contexts, keine einschüchternde Terminologie. Nur Events, die erfassen, was passiert, benannt so, wie das Business sie benennt.

Das heißt mit anderen Worten: Event Sourcing ist ein Katalysator für Domain-Driven Design.

Kundinnen und Kunden DDD zu erklären ist schwer. Die Terminologie schüchtert ein. Die Konzepte sind abstrakt. Viele Entwicklerinnen und Entwickler (mich eingeschlossen) haben sich irgendwann „zu dumm“ für DDD gefühlt, erschlagen von der Theorie.

Aber Events zu erklären ist einfach. Jede und jeder versteht Events. „Was ist passiert?“ ist eine Frage, die Menschen stellen, seit es Sprache gibt. Und wenn man Teams dazu bringt, ihre Events präzise zu benennen, machen sie am Ende ganz natürlich DDD. Sie beginnen, die Sprache der Domäne zu sprechen. Sie beginnen, Gespräche mit Domänenexpertinnen und -experten zu führen. Sie beginnen, Systeme zu bauen, die die Realität widerspiegeln, statt Datenbanktabellen.

Wer also auf die eigenen Events schaut und überall Created, Updated und Deleted sieht, hat die Chance, nicht nur das Event-Modell zu verbessern, sondern ein Gespräch darüber zu beginnen, was im eigenen Business tatsächlich passiert. Wie nennt man es, wenn ein Drucker hinzugefügt wird? Wenn eine Nutzerin oder ein Nutzer geht? Wenn eine Bestellung storniert versus erstattet versus angefochten wird?

Die Antworten auf diese Fragen verraten mehr über die Domäne als jeder Musterkatalog es je könnte.

Wenn Ihnen das bekannt vorkommt, fangen Sie hier an: Schauen Sie sich Ihre Events an! Lesen Sie sie laut vor! Klingen sie wie Datenbankoperationen, oder klingen sie wie Dinge, die in Ihrem Business passieren?

Für einen tieferen Einblick in die Konzepte hinter DDD und Event-Sourcing erklären diese Einführungen in Domain-Driven Design und Event-Sourcing die Grundlagen.

Denn Events sollten eine Geschichte erzählen, keinen Polizeibericht.


(rme)



Source link

Entwicklung & Code

Go-Entwickler nutzen oft KI-Tools – sind aber wenig begeistert


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Das Team hinter Googles Programmiersprache Go hat die Community befragt, und es haben über 5000 Go-Developer geantwortet: Sie nutzen häufig KI-Tools für Informationssuche und Coding, sind mit diesen aber nur mittelmäßig zufrieden. Mit der Programmiersprache an sich sind die Go-Developer dagegen fast durchweg zufrieden: Das gaben 91 Prozent an.

Weiterlesen nach der Anzeige

Die Freitextantworten geben Aufschlüsse über die Gründe der Beliebtheit. Hierbei nennt das Go-Team als repräsentative Antwort unter anderem, dass andere Sprachen zu komplex seien, Go dagegen vergleichsweise klein und einfach. Eine andere Antwort betont die gute Skalierbarkeit der Sprache, die sowohl für einzelne Programmierer als auch für große Teams geeignet sei. Weitere Antworten heben das Tooling, die Standard Library und das Go-Ökosystem positiv hervor.

Die Schwierigkeiten bei der Go-Entwicklung wurden ebenfalls abgefragt. Die Top 3 der frustrierendsten Aspekte sind „Sicherstellung, dass Go-Code Best Practices und Go-Idiomen folgt“, „Ein Feature, das ich in einer anderen Programmsprache schätze, ist nicht in Go vorhanden“ und „Auffinden vertrauenswürdiger Go-Module und -Pakete“. Auch die Dokumentation und das Testing von Go-Code sowie das Erlernen von Go-Modulen finden viele der Entwicklerinnen und Entwickler schwierig.


2025 Go Developer Survey: Diese Dinge führen zur Frustration mit Go. Die Teilnehmenden durften drei Antworten auswählen.

2025 Go Developer Survey: Diese Dinge führen zur Frustration mit Go. Die Teilnehmenden durften drei Antworten auswählen.

2025 Go Developer Survey: Diese Dinge führen zur Frustration mit Go. Die Teilnehmenden durften drei Antworten auswählen.

(Bild: Google)

Über die Hälfte der Befragten nutzt täglich KI-Tools, während 29 Prozent diese entweder nie verwenden oder nur wenige Male innerhalb des Monats vor der Umfrage genutzt haben. Die am häufigsten genutzten KI-Assistenten sind ChatGPT (45 Prozent), GitHub Copilot (31 Prozent), Claude Code (25 Prozent) und Gemini (20 Prozent). Direkt auf dem fünften Platz folgt jedoch bereits mit 17 Prozent: „Ich verwende keine KI-Assistenten oder -Agenten, wenn ich Go-Code schreibe“.

Die Einsatzzwecke von KI sind vielfältig und gehen über das Schreiben von Code hinaus. Beispielsweise lernen Entwickler damit neue Konzepte, suchen nach Informationen, nutzen KI für Testing und reviewen ihren selbst geschriebenen Code. Den Code anderer Personen möchte allerdings ein Drittel nicht mit KI-Unterstützung reviewen, und für das Deployment einer Software zur Produktion lehnen die Befragten KI mehrheitlich ab.

Weiterlesen nach der Anzeige


2025 Go Developer Survey: Go-Entwicklerinnen und -Entwickler nutzen KI für vielfältige Anwendungsbereiche.

2025 Go Developer Survey: Go-Entwicklerinnen und -Entwickler nutzen KI für vielfältige Anwendungsbereiche.

2025 Go Developer Survey: Go-Entwicklerinnen und -Entwickler nutzen KI für vielfältige Anwendungsbereiche.

(Bild: Google)

Die Zufriedenheit mit den KI-Tools ist durchwachsen: Sehr zufrieden sind lediglich 13 Prozent, einigermaßen zufrieden („somewhat satisfied“) 42 Prozent. Unzufrieden sind 16 Prozent, sehr unzufrieden sieben Prozent. Die übrigen 22 Prozent sind neutral. Als Hauptproblem in Bezug auf KI-Entwicklertools gibt die Mehrheit nicht funktionierenden Code an, während knapp ein Drittel auch die Qualität des funktionierenden KI-generierten Codes bemängelt.

In diesem Jahr fragte das Go-Team auch danach, was – neben Go – die andere Lieblingssprache der Programmiererinnen und Programmierer ist. Dabei stehen bei ihnen Python, Rust, TypeScript, C und Java ganz oben. Das Go-Team sieht hier das Potenzial, spezialisierte Tutorials zu erstellen, zum Beispiel „Error Handling in Go für Java-Entwickler“. Auch könne ein Teil solcher Anleitungen in Code-Analyzer integriert und somit direkt innerhalb einer IDE verfügbar gemacht werden.

Der 2025 Go Developer Survey fand vom 9. bis 30. September 2025 statt und ergab 5379 gültige Antworten. Von diesen arbeiten 87 Prozent als Entwicklerinnen und Entwickler. Die Befragten setzen Go vorrangig beruflich (82 Prozent) und privat beziehungsweise für Open-Source-Projekte (72 Prozent) ein, und ein Drittel hat bereits mehr als sechs Jahre Erfahrung mit Go vorzuweisen.

Weitere Informationen zu den Ergebnissen finden sich auf dem Go-Blog. Die Rohdaten sollen im ersten Quartal dieses Jahres ebenfalls erscheinen. Allerdings werden darin nur die Antworten der Personen, die dieser Veröffentlichung zugestimmt haben (82 Prozent), enthalten sein.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Anthropic überarbeitet Verhaltensrichtlinien für KI-Modell Claude


Die KI-Entwicklungsfirma Anthropic hat die Verhaltensrichtlinien grundlegend überarbeitet, nach denen das Large Language Model (LLM) Claude agiert. Die so genannte „Constitution“ sei erstmals nicht mehr eine reine Aufzählung von Anweisungen, heißt es in einem begleitenden Blogpost, sondern versuche den Modellen jetzt auch zu vermitteln, warum der KI diese Vorgaben gemacht werden.

Weiterlesen nach der Anzeige

Anthropic verspricht sich davon, dass die Modelle durch das Verständnis der Regeln deren Sinn und Absicht auch auf Szenarien übertragen können, die nicht explizit in dem bisherigen Prinzipiendokument aufgeführt wurden. Zugleich strahlt der Schritt aus, dass der KI-Entwickler seinen Modellen für die Zukunft menschenähnliche Fähigkeiten zutraut. Die Leitlinien sollen offenbar auch vorsorgen, dass die KI, wenn sie mal Bewusstsein erlangt, nicht ein menschengewolltes Herunterfahren verhindert. An anderer Stelle heißt es jedoch, dass die menschliche Ansprache vor allem dazu diene, um dem Modell zu zeigen, dass menschliche Qualitäten erstrebenswert seien.

Die „Constitution“ zeigt den Modellen aber auch klare Grenzen auf, wo die Entwickler der KI offenbar nicht zutrauen, dass sie das von selbst erkennt. Dazu zählten Hilfe beim Bau von Massenvernichtungswaffen oder Unterstützung bei Völkermord sowie jede Beteiligung an der Erstellung von kinderpornografischem Material. Anthropic hat seinem Modell aufgetragen, im Zweifelsfall Sicherheit vor Ethik zu stellen. Das heißt, dass zum Beispiel das Untergraben der menschlichen Kontrolle selbst dann nicht erfolgen soll, wenn ein Modell das als ethisch richtig erkennen würde.

Anthropic hat seine Leitlinien unter der „Creative Commons CC0 1.0“-Lizenz veröffentlicht. Dadurch ist sie frei und ohne Genehmigung für jeden Zweck nutzbar. Die neuen Vorgaben werden auch in verschiedenen Trainingsphasen eingesetzt und in der Erzeugung synthetischer Trainingsdaten.

Weiterlesen nach der Anzeige

Ob die KI tatsächlich das gewünschte Verhalten zeigt oder durch den neuen Ansatz davon abweicht, soll in den so genannten System Cards dokumentiert werden, die in der Vergangenheit schon Risiken und Schwächen der Modelle untersucht haben. Anthropic betont, dass auch externe Experten aus den Bereichen Recht, Philosophie, Theologie und Psychologie in die Entwicklung eingebunden waren. Die neuen Leitlinien sind bei allen aktuellen Claude-Modellen im Einsatz.


(mki)



Source link

Weiterlesen

Entwicklung & Code

Open Responses: Einheitliche LLM-Schnittstelle statt Adapter-Chaos


Mit Open Responses ist ein Open-Source-Standard für eine herstellerunabhängige JSON-API erschienen, über die Sprachmodelle mit Clients kommunizieren. Sie basiert auf Responses API und stellt einen weiteren Baustein des agentischen KI-Ökosystems der Firma dar.

Weiterlesen nach der Anzeige

Zusammen mit der Responses API hatte OpenAI letztes Jahr integrierte Tools und ein Software Development Kit (ADK) vorgestellt, mit deren Hilfe sich eigene KI-Agenten erstellen lassen. Die Responses API kombiniert die Chat Completions API sowie die Assistent API von OpenAI und kann eigenständig agieren, statt sich auf das Liefern von Antworten zu beschränken. Bislang war für jedes LLM jedoch ein eigener Client-Adapter erforderlich. Dies soll Open Responses nun vereinheitlichen.

OpenAI will den offenen Standard in den kommenden Monaten zusammen mit der Community und Anbietern von Interferenzlösungen weiterentwickeln. Dazu konnte OpenAI Hugging Face, Nvidia, LLM, LM Studio, Ollama, OpenRouter und Vercel als Launch-Partner gewinnen.

Mozilla hat mit any-llm bereits ein ähnliches Projekt am Start. Das Python-Paket ist eine einheitliche API für viele LLMs und erspart es Entwicklerinnen und Entwicklern, für jedes einzelne LLM einen eigenen Adapter pflegen zu müssen.

Um die KI-Interoperabilität zu verbessern, definiert Open Responses ein „gemeinsames Schema und eine Werkzeugschicht, um den Aufruf von Sprachmodellen, das Streaming von Ergebnissen und die Zusammenstellung agentenbasierter Workflows zu vereinheitlichen“. Das soll unabhängig vom Anbieter funktionieren.

Entwicklerinnen und Entwickler, die bereits die Responses API nutzen, können laut OpenAI ohne großen Aufwand auf das neue Format umsteigen. Die Änderungen sollen größtenteils die agentische Argumentation betreffen. Dafür stehen neben encrypted_content (anbieterspezifische geschützte Inhalte) und summary (aus den Reasoning Traces bereinigte Daten) und dem neuen content (Reasoning Traces) nun drei Eingabeparameter zur Verfügung. Letzterer erlaubt es, die Reasoning Traces über die API zugänglich zu machen, was einen Anbieterwechsel leichter macht.

Weiterlesen nach der Anzeige

Im Fall des KI-Delta Learnings sehen die Funktionsaufrufe für Open Response im Vergleich zu Responses API folgendermaßen aus:


// Open weight models stream raw reasoning
event: response.reasoning.delta
data: { "delta": "User asked: 'Where should I eat...' Step 1: Parse location...", ... }

// Models with encrypted reasoning send summaries, or sent as a convenience by Open Weight models
event: response.reasoning_summary_text.delta
data: { "delta": "Determined user wants restaurant recommendations", ... }


Wer sich genauer in das agentische Open-Source-Modell einlesen will, findet auf der dessen Webseite eine technische Beschreibung.


(who)



Source link

Weiterlesen

Beliebt