Skip to content

Wann reicht CRUD?

This content is not available in your language yet.

CRUD (Create, Read, Update, Delete) ist die richtige Wahl für viele Systeme. Es ist kein Kompromiss. Es ist eine bewusste Entscheidung.

  • Die Domäne ist dünn: Formulare, Listenansichten, Stammdatenpflege. Keine komplexen Invarianten, keine Domain-Events, keine tiefen Aggregat-Grenzen.
  • Das Team ist klein: DDD-Overhead ohne DDD-Nutzen ist Overengineering.
  • Die Anforderungen sind stabil: Wenn sich Geschäftsregeln selten ändern, lohnt sich die Flexibilitätsinvestition nicht.
  • Der Zeithorizont ist kurz: Für kurzlebige Systeme ist Einfachheit ein Vorteil.
  • Validierungen werden komplexer und hängen von anderen Aggregaten ab
  • Business-Regeln landen in SQL-Stored-Procedures oder API-Middleware
  • Zustandsübergänge werden relevanter als Feldwerte
  • Das Team diskutiert wiederholt über den richtigen Ort für Logik

CRUD in einem System zu bauen, das eigentlich DDD braucht — und es dann nie zu ändern, weil Refactoring „keine Zeit hat”.

CRUD ist eine valide Architekturentscheidung, keine Ausrede. Aber sie muss eine Entscheidung sein — nicht die Abwesenheit einer.