ugrás a tartalomhoz

DDD terén tudnátok segíteni?

inf3rno · Jan. 6. (H), 18.14
Sok dolog nem világos DDD-vel kapcsolatban, és nem találok rá választ, bárhogyan keresem. Általános dolgokra persze van válasz, hogy aggregate root-ot hogyan kell választani, meg hogy mi entity, mi value object, mekkora egy bounded context, ilyesmik. Nem tudom, hogy ennyire specifikus a problémám, vagy egyszerűen a DDD nem foglalkozik a kérdéssel, és oldjam e meg, ahogy tudom. Nyilván a problémát meg tudom oldani, de szeretnék fejlődni DDD-ben is. Az egész cucc egy nodejs daemonban futna egyelőre, később talán szétskáláznám földrészenként, ha szükséges.


Nagyjából arról van szó, hogy van egy előrejelző szolgáltatás (ForecastingService), amitől bizonyos időközönként elkérem a friss előrejelzéseket (Forecast). A felhasználók (User) feliratkoznak (Subscription) értesítésekre (Notification) ezekkel kapcsolatban. Az, hogy valaki kap e értesítést függ a tartózkodási helytől (Location), az arra a helyre vonatkozó előrejelzéstől (LocalForecast(Forecast, Location)), a felhasználó beállításaitól (NotificationSettings), és egy viszonylag bonyolult algoritmustól, ami ezek alapján dönt. Igy első körben azt mondanám, hogy értesítő szolgáltatást nyújtok (NotificationService), ami a fent említett algoritmust magába foglalja.

Ami mentésre kerül az a User, a Settings és a Subscription. A Forecast-et is menteni szeretném, de csak azért, hogy egy másik alkalmazással kielemezzem később, tehát ennél az alkalmazásnál nem olvasnám vissza, de jó lenne, ha bekerülne az event storage-be. A Notification-t is jó lenne menteni, mert jó lenne, ha nem menne el sorozatban egy tucatszor ugyanaz az értesítés.

1.
Itt azt hiszem egyértelmű, hogy szükség van legalább egy setInterval-ra, hogy tudjam folyamatosan frissíteni az előrejelzéseket. Ami nem világos DDD-vel kapcsolatban, hogy ennek a setInterval-nek hol a helye. Mármint valószínűnek tartom, hogy csinálnom kell egy NotificationService példányt az elején, ami elindítja az egészet, és felügyeli a frissítést. Ami nem világos, hogy ez melyik rétegben kell, hogy helyet kapjon, szóval hogy ez most application service vagy esetleg domain service vagy valami teljesen más?

2.
Az sem teljesen világos, hogy az elején hol kellene példányosítani, és elindítani a NotificationService-t, hogy csinálja a dolgát. Általában szokott lenni valami app.start() jellegű kód az index.js-ben, szóval gondolom oda kell, hogy bekerüljön ez a logika is, de nem világos, hogyha a domain-be tesszük, mint domain service-t, akkor van e erre valami általánosan elfogadott best practice. Mondjuk lehetne a domain-en belül java-hoz hasonlóan egy main függvényt megadni, ami automatikusan meghívásra kerül, vagy ilyesmi. Szóval van erre valami bevett dolog?

3.
Tegyük fel, hogy megvan, hogy mi tartja fenn az előrejelzések frissítését. Ami nem világos, hogy mennyire megszokott vagy engedélyezett az, hogy csak egyetlen Forecast object-em van, nevezhetjük akár singleton-nak is, és arra tolok update-et folyamatosan. Eddig erre példát sehol nem láttam, de én jó megoldásnak tartom. Jóval megszokottabb alternatíva, hogy van egy Forecast repom, és minden alkalommal új Forecast-et hozok létre, amit a repoba mentek. Egyik sem okoz különösebb nehézséget, csak érdekel, hogy az első belefér e a DDD-be, vagy esetleg valamiért antipattern?
 
1

Egyelőre úgy tűnik, hogy

inf3rno · Jan. 9. (Cs), 20.06
Egyelőre úgy tűnik, hogy saga-t vagy valamilyen domain service-t kellene csinálnom az elsőre. A másodikra majd nézek pár példát. A harmadiknál több értelmét látom annak, hogy a Forecast value object és minden frissítéskor kiszórok egyet belőle. Esetleg a letároláshoz csinálok domain eventet, ami ugyanazt tartalmazza, csak valamilyen szerializálható formában. Talán olyan szempontból lenne mégis értelme egy entity-nek, hogyha újraindítom, akkor be tudja tölteni a legutóbbi állapotot, és ne kelljen újra lekérnie a külső webszolgáltatásoktól, de erre meg be tudok tenni valamilyen cache-t, ami szintén megoldja.
2

Hello, 1) semmi akadályát

Crystal · kedd, 10.05
Hello,

1) semmi akadályát nem látom, hogy a domain rétegbe menjen a setInterval()

2) a DDD könyv beszél egy úgynevezett "application layer"-ről, ami az alkalmazás interfésze és a domain réteg között van. Amennyire értem, ez a réteg arra való, hogy a "kívülről" jövő hívások paraméterei alapján referenciát szerezzen a domain objektumokra ill. meghívja azok metódusait. Én ide tenném ezt az app.start() hívást. Az application layert meg használhatja az index.js (szóval a külső réteg). Én nem gyógyítanám bele az app.start() hívást a domain rétegbe, mert annak inkább library-szerű kódnak kellene lenni, annak meg nincs "főprogramja".

3) nem mondja a DDD, hogy nem lehetnek mutable singletonjaid, szóval szabadni éppen szabad. Bár én nem tenném. Inkább egy rx streamen keresztül küldenék immutable Forecast példányokat. A módosítható globális objektum mondjuk DDD-től függetlenül, általánosságban antipattern. De ez ízlés kérdése / konkrét usecase-től függ.

ui.: kicsit meg vagyok lepődve, hogy a weblabor nem teljesen halott :D