ugrás a tartalomhoz

DDD terén tudnátok segíteni?

inf · 2020. 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

inf · 2020. 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 · 2020. Jan. 28. (K), 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
3

Köszi! Egyetértek

inf · 2020. Jan. 31. (P), 04.45
Köszi! Egyetértek mindegyikkel. Abban gondolkodok most, hogy csinálok egy Scheduler interface-t a domain-ben, és azt implementálom majd az infrastructure-ben a setInterval-al. Igy be lehet tenni tisztán is a domain-be, nem kell függenie a setInterval-os implementációtól. A main is jó helyen van az application layerben szerintem. Onnan állítom be majd a Scheduler-t, hogy fix időközönként kérje el a Forecast value objecteket a ForecastService-től. Közben gondolkodtam, és ami fontos, azt ki tudom nyerni már most pár mentett Forecast alapján, úgyhogy szerintem nem lesz szükség a mentésére, elég ha csak a memóriában él. A ForecastService domain service szintén legalább részben az infrastructure-ben lesz implementálva, és ő fogja elkérni a külső szolgáltatóktól az előrejelzést. Azt hiszem ezzel elég jól le van fedve a dolog. Saga meg ilyen application layeres dolgok nem fognak kelleni így a ciklushoz, és nincs feleslegesen túlbonyolítva, meg az is érthető a kód alapján, hogy mit csinál.

Arra jöttem rá közben, hogy nincs értelme annyira mereven ragaszkodni a DDD-s dogmához, mert akkor még jó pár könyvet el kéne olvasnom, hogy minden helyzetre legyen valami kész megoldásom. Egyszerűbb egy kicsit lazábban kezelni, aztán esetleg később refaktorálni, újratervezni, ha szükséges. Működni így is működni fog a kód, amit írok, meg eléggé OO lesz.

ui:
Csak azért járok még ide, mert magyar nyelven nincs más fórum, amin ilyesmiket meg lehetne beszélni. Volt róla szó régebben, hogy csinálunk egy saját fórumot, de mindenkinél leült a kezdeti lelkesedés. Páran még blogolnak innen, pl most éppen Janoszen blogjára találtam rá. Én is írtam egy darabig, de már semmi értelmét nem látom. Nem tudom még meddig marad fent ez az oldal. Valaki a háttérből néha kitörli a botok üzeneteit, de ezen kívül mostanában semmi más nem történt és a mostanában az elmúlt 5 évet jelenti. :D
4

kevés szabadidő

Pepita · 2020. Jan. 31. (P), 08.06
Volt róla szó régebben, hogy csinálunk egy saját fórumot, de mindenkinél leült a kezdeti lelkesedés.
Szerintem ennek leginkább a túl kevés ráfordítható idő az oka, bár lehet, hogy egy kicsit túltoltuk az elején a módszertant is. :)
És igen: nagyon sok idő (munka) egy egy cikk megírása is, ha ezeket csak páran olvassák, nem valami motiváló...
5

Ja lehet. A blogolást én is

inf · 2020. Jan. 31. (P), 21.12
Ja lehet.

A blogolást én is azért hagytam abba, mert sok idő még egy blog bejegyzést is valami olvasható formában összeszedni, és ahhoz képest meg kevesen olvassák. Egy cikknél még ennél is több munka van vele. Angolul talán még van értelme, de már abban is kételkedem.