Archívum - Jan 18, 2016 - Fórum téma
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!
■ Domain.hu: nyilvános privát adatok
Szerintetek miért van az, hogy a HU domainoknál a domain.hu oldalon a privát személyek neve, címe, telefonszáma is nyilvános, miközben a COM, EU domainoknál megoldható, hogy ne legyen az.
Nem tudom ti hogy vagytok vele, de a mai világban nem szívesen teszem ki mindenki számára elérhető módon a nevem, címem. Így kénytelen vagyok nem HU domaint használni.
Írtam a domain.hu-nak, de bsztak válaszolni.
■ Nem tudom ti hogy vagytok vele, de a mai világban nem szívesen teszem ki mindenki számára elérhető módon a nevem, címem. Így kénytelen vagyok nem HU domaint használni.
Írtam a domain.hu-nak, de bsztak válaszolni.