ugrás a tartalomhoz

Egy vagy több event storage illik egy projekthez több bounded context-el?

inf · 2016. Jan. 18. (H), 18.47
Olvasgatok DDD témában, és sehol nem találtam infot arról, hogy az event storage-et hogyan érdemes alkalmazni. Elméletileg minden bounded context-nek olyasminek kellene lennie, mint egy-egy önálló alkalmazás, ami esetleg a felületén keresztül valamilyen megoldással (rest+acl, message queue, stb.) kommunikál a többi bc-vel, ha erre szükség van. Nem véletlen nem igaz ezekre a DRY szabály sem, megjelenhet ugyanaz a property esetleg entity egy másik bc-ben is, ha erre szükség van. Logikus, hogy azért nem érvényes ez a szabály, mert a másik bc már másik alkalmazásnak számít, és ezek a DDD-s megoldások igazán nagy projektekre lettek szabva, ahol egy új alkalmazás létrehozása indokolt is. Ezek alapján én arra következtetek, hogy cqrs-el használva minden bc-hez jó külön event storage-t is létrehozni, ami letárolja az eseményeket az adott kontextusra vonatkozólag. Ennek több előnye is van szerintem, de érdekelne valaki olyan véleménye, mint pl szjani, aki tapasztalt a témában, és tudja, hogy a gyakorlatban mi az, ami beválik. Köszönöm a válaszokat!
 
1

Szerintem erre ökölszabály

szjanihu · 2016. Jan. 18. (H), 20.06
Szerintem erre ökölszabály nincs és elég soktényezős a dolog. Ha eltérő csapatok dolgoznak ez egyes BC-ken, akkor lehet nem is látják egymás storage-át, vagy mondjuk adott subdomainra magasabb security ruleok vonatkoznak és explicite tiltva van, hogy más lássa az abban emittált eventeket. Szóba jöhet még a performancia, vagy akár az, hogy egyik helyen elegendő egy nosql megoldás, míg máshol szükség van tranzakciókezelésre.

Érdemes úgy gondolkodni, hogy könnyen cserélhető legyen az implementáció. Így az elején lehet 1 storage és később, ha valamilyen oknál fogva bizonyos helyen az nem megfelelő, akkor ott követhetsz más stratégiát. Ez kellőképpen rugalmas és nincs overheadje.
2

Okés, köszi!

inf · 2016. Jan. 19. (K), 04.18
Okés, köszi!