Aggregate-Designer

Teil des Designer-Guides. Voriger Schritt: Bounded-Context-Editor · Nächster: Process-Designer.

Ein Aggregat ist die Konsistenzgrenze deines Modells. Im Aggregate-Designer legst du fest, welche Tabellen dazugehören, welche Entität die Root ist und wie sie zusammenhängen, als ER-Diagramm. Ein Klick auf Build erzeugt daraus den vollständigen Code-Baum.

Die Tabs

Der Designer führt von der Tabellenauswahl bis zum fertigen Code, alles in einer Oberfläche:

Tab	Was du siehst
Tables	Das importierte BC-Schema — Tabellen, Spalten, Schlüssel. Hier wählst du die Teilmenge, die zum Aggregat gehört.
Designer	Der ER-Canvas: Tabellen als Knoten, Beziehungen als Kanten.
Code	Der generierte PHP-Code, read-only im Browser. Siehe Code, API & Reports.
API	Die exponierte Command-/Query-/Event-Oberfläche des Aggregats, read-only.
Report / Validation	Build-Status und Validator-Befunde.

Schritt für Schritt

1. Tabellen wählen — im Tables-Tab die Tabellen des Aggregats aus dem BC-Schema auswählen. Sie erscheinen als Knoten auf dem Canvas.
2. Root markieren — über den Set-as-Root-Kopf am Knoten legst du die Wurzel-Entität fest. Sie ist die einzige Tür in den Entity-Graphen.
3. Beziehungen ziehen — Kanten zwischen Knoten bilden die ER-Struktur ab (PK/FK/UK/IK). Eine frisch gezogene Kante ist sofort ausgewählt und wird im Seitenpanel bestätigt oder verworfen.
4. Details pflegen — pro Knoten öffnet rechts ein Seitenpanel (siehe unten).
5. Speichern & Bauen — Save sichert den Stand; Build erzeugt den Code.

Das Knoten-Seitenpanel

Pro Knoten öffnet ein Seitenpanel mit zwei Tabs:

• Defaults — Vorbelegungen in zwei Modi. onCreate setzt Werte einmalig bei der Geburt (Konstanten, UUID7, FK-Referenzen wie <entity>.id). sync vererbt Vorfahren-Felder (<entity>.field) bei jedem Persistieren erneut. Der Modus ergibt sich automatisch aus dem Werttyp: eine falsche Platzierung ist hier nicht möglich.
• Order — die OrderBy-Sortierung für 1:n-Beziehungen.

Das Kanten-Seitenpanel

Klickst du eine Kante an, erscheint im selben Seitenpanel ihre Variante: Eltern/Kind tauschen, 1:1- vs. 1:n-Kardinalität und (bei aggregat-internen Kanten) der Schalter required / optional (die Existenz-Invariante der Beziehung, Standard required). Auf dem Canvas ist das direkt sichtbar: eine required-Kante wird durchgezogen gezeichnet, eine optional-Kante gestrichelt und leicht abgeblendet.

Auto-Layout

Ein Kebab-Eintrag Auto-Layout ordnet den Graphen hierarchisch von links nach rechts entlang der Kanten; unverbundene Tabellen sammelt er als kompakten Block darunter. Das ändert nur die Positionen im Speicher: sie werden erst beim nächsten Save/Build gesichert.

Entwurf und Build-Sperre

Save gelingt immer. Ist der Canvas inkonsistent (z. B. eine Tabelle ist von der Root nicht erreichbar), sichert Jardis den Stand als Entwurf statt mit einem Fehler abzubrechen: der letzte konsistente Stand bleibt unangetastet. Ein Entwurf-Badge erscheint, mit der Kebab-Aktion „Entwurf verwerfen".

Solange ein Entwurf offen ist, ist Build blockiert, an jedem Einstiegspunkt (Build-Dialog, headless-Build, CLI). Headless meldet sich das als DRAFT_EXISTS-Fehler (MCP).

Vom Modell zum Code

Ein Build erzeugt pro Aggregat einen hermetischen, generator-eigenen Baum unter {BC}/Aggregate/{Agg}/. Niemals von Hand editieren. Darin liegen zwei Fassaden:

• Read-Fassade {Agg}Read — die „Außentür": get{Agg}ById / ByIds / By{Key} und {agg}List. Erreichbar über die BC-Fassade: $bc->{agg}().
• Write-Fassade {Agg} — Commands und event(); nur familienintern über die Kernel-Naht erreichbar, nicht von der Transportschicht aus.

Schreibende Abläufe laufen deshalb über Prozesse, nicht direkt gegen das Aggregat. Wie du den erzeugten Code anbindest, zeigt Get Started; die Tiefe steht in den Skills (platform-usage, platform-implementation).

Neue Operation nötig?

Eine neue Aggregat-Operation entsteht durch Neu-Modellieren im Designer, nicht durch Hand-Edit am Generat. Ein Ablauf über mehrere Aggregate hinweg gehört in einen Prozess.