[sarveniusz]

Korzystam z broadway i mam taki kod:

https://pastebin.com/PcD4ijTQ

Tyle, że gdyby nie broadway i event sourcing, to pewnie trzymałbym w encji Subscription nie planId tylko po prostu obiekt Plan i wtedy w metodzie upgrade mógłbym sobie sprawdzić $this->plan->canBeUpgradeWith($plan), problem polega na tym, że mam planId. Wyciągnięcie tego sprawdzenia na zewnątrz encji wydaje mi się błędem, pytanie czy macie na to jakiś sposób? Jak takie przypadki realizujecie?

Wrzucenie Plan, Client zamiast planId, clientId do Subscription powoduje taki problem, że w zdarzeniach dotyczących Subskrypcji będę musiał serializować również całe obiekty Plan i Client.

#webdev #php

[ghost1511]

@sarveniusz: Wydaje mi się że najbliżej logiki byłby jednak PlanService który by sprawdzał czy plan może zostać rozszerzony. A sama zmiana następowałaby w subskrypcji. Ale jestem ciekawy innych odpowiedzi :)

Wrzucenie Plan, Client zamiast planId, clientId do Subscription powoduje taki problem, że w zdarzeniach dotyczących Subskrypcji będę musiał serializować również całe obiekty Plan i Client.

Przy zapisie raczej i tak powinieneś zapisać tylko ID, a nie cały obiekt. Natomiast w warstwie

[MQs]

@sarveniusz: Możesz ustawić Plan przez konstruktor, a do eventa dać samo id. Ta śmieszna metoda ustawiająca właściwości nie jest potrzebna.
Zresztą, pomyślałbym nad spójnością trochę, bo nie wiadomo czy te obiekty traktować jako VO czy BO - w pierwszym przypadku wyciągnięcie logiki na zewnątrz (do odpowiedniego kontekstu) będzie się już wydawać właściwe, a w drugim obiekt sam będzie zamkniętym kontekstem - dla "subscription change" będzie miał metodę upgrade(), dla view będą

[sarveniusz]

@MQs: w sensie ta metoda applyNazwaZdarzenia jest niepotrzebna? Z tego co widziałem to w broadwayu właśnie tak to jest realizowane. Pytanie więc w jaki sposób inaczej te zdarzenia mają być "nanoszone" na obiekt? Dokumentacja broadwaya chyba nie istnieje, są tylko przykłady, więc może coś przeoczyłem.

[MQs]

@sarveniusz: Chyba rzeczywiście ta metoda będzie potrzebna, bo obiekt będzie tworzony od środka po nakarmieniu go zdarzeniami. W takim razie potraktowałbym ten obiekt jako płaskie dane i uciekał z logiką na zewnątrz.