CQRS

Bevor du irgendeine API-Referenz liest, verinnerliche das hier: Die gesamte etg24-Integrationsfläche ist in zwei Arten von Operationen aufgeteilt.

Commands ändern Zustand, Queries lesen Daten

• Queries lesen Daten. Sie ändern nie etwas. Sicher zu wiederholen, sicher mit Read-only-Keys auszuführen.
• Commands ändern Zustand – anlegen, ändern, löschen. Sie sind explizite, gezielte Aktionen mit Audit-Trail.

In der REST API ist diese Trennung direkt in der URL sichtbar:

GET  /propertymanagement/v2/query/contacts           Liste lesen
POST /propertymanagement/v2/command/contacts.create  Kontakt anlegen

Im MCP gilt dieselbe Trennung: Jedes Tool ist entweder ein Query- oder ein Command-Tool, und die Tool-Referenz kennzeichnet jedes einzelne. Ein Query-Tool rufst du ohne Bedenken auf; ein Command-Tool rufst du bewusst auf.

Warum das für dich wichtig ist

CQRS ist kein Implementierungsdetail – es ist das Denkmodell für alles, was du auf der Plattform baust:

• Read-only-Berechtigungs-Scopes bilden sich direkt auf Queries ab. Ein Key mit Lese-Scope kann jede Query und keinen Command ausführen. Siehe Berechtigungs-Scopes.
• Commands sind die Grenze der Auditierbarkeit. Jeder Command wird aufgezeichnet und exakt dem Agenten zugeordnet, der ihn ausgeführt hat. Siehe Änderungszuordnung – und Rollback für den Wiederherstellungs-Ablauf.
• Rollback ist möglich, weil Soft Delete die meisten destruktiven Commands reversibel macht.

Eine Faustregel

Wenn du eine Integration oder einen Agenten entwirfst, frage bei jeder Operation: Verändert sie die Welt? Wenn nicht, ist es eine Query – lesend, wiederholbar, risikoarm. Wenn ja, ist es ein Command – gescoped, auditiert und sorgfältig zu testen.