Ein neuer Kontext kommt dazu, und plötzlich soll ein Vorgang aus dem einen im anderen etwas auslösen. Der erste Reflex ist der direkte Aufruf — genau dort, wo die Änderung passiert. Das funktioniert, und es kostet mehr, als es aussieht.
Der direkte Aufruf dreht die Abhängigkeit um
Bisher wusste nur der eine Kontext vom anderen. Steht der fremde Aufruf erst einmal im Code, wissen beide voneinander, und jede Änderung auf der einen Seite schlägt auf die andere durch. Die Variante „den Empfänger als Parameter übergeben” verschiebt das nur: Die Bindung bleibt, und die Entity bekommt eine Aufgabe, die fachlich nicht ihre ist.
Ein Ereignis ist fachlich, nicht technisch
Ein Domain Event beschreibt etwas, das in der Domäne geschehen ist und für sie Bedeutung hat. Der Knopfdruck auf einem Bedienfeld ist keins, der dadurch gestartete Vorgang schon. Die Frage lautet nie „was ist passiert”, sondern „interessiert es den Fachbereich”.
Beim Entwurf tragen ein paar Regeln fast alles:
- Vergangenheitsform — eine Tatsache, keine Anweisung
- nur die Angaben, die der Empfänger zum Reagieren braucht
- ausschließlich einfache Datentypen, nie Entities oder Value Objects
Regel drei ist die, gegen die am häufigsten verstoßen wird. Wer die ganze Entity mitschickt, „damit nichts fehlt”, verbindet die Kontexte wieder — nur an einer Stelle, an der es niemandem auffällt.
Erzeugen und Zustellen sind zwei Dinge
Das überraschende Detail: Die Entity löst das Ereignis nicht aus. Sie merkt es sich nur in einer geschützten Sammlung. Zugestellt wird erst, nachdem das Aggregat gespeichert ist — vorher kann eine Prüfung den Vorgang noch abbrechen, und ein bereits verarbeitetes Ereignis ließe sich dann nicht zurücknehmen. Nebenbei bleibt der Kern frei von Infrastruktur, und der Test liest die Ereignisse einfach von der Entity ab.
Mehr dazu im Seminar
Wie ein solches Ereignis entsteht, wo sein Behandler liegt und warum die Zustellung in die Infrastruktur gehört, zeigt das Modul Domain Events — inklusive Video und Kapitelübersicht.