Egy vagy több event storage illik egy projekthez több bounded context-el?
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!
■
Szerintem erre ökölszabály
É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.
Okés, köszi!