Please enable JavaScript.

Coggle requires JavaScript to display documents.

CQRS - Coggle Diagram

- - - - max 1 aktywna interaction
      - TTL
      - transfer zamyka jedną i otwiera nową
  - - - jest bezstanowy,
      - działa jednorazowo: przychodzi komenda → wykonuje → koniec,
      - nie pamięta niczego między requestami,
      - nie ma własnego lifecycle,
      - nie słucha eventów,
      - nie czeka w czasie (no timers/schedulers),
      - nie ma retry logic,
      - nie inicjuje własnych timeoutów.
    - - ma własny stan i lifecycle, trwa minuty / godziny,
      - reaguje na wiele eventów w czasie,
      - wysyła wiele komend do różnych agregatów,
      - koordynuje proces, nie wykonuje jednej operacji,
      - może mieć retry, timeout, compensations,
      - może konsumować eventy z wielu serwisów,
      - może „czekać” na warunek (np. agent dołączy).
    - - Application Service To jak kelner → bierze zamówienie → przynosi jedzenie → finito.
      - Saga - To jak wedding planner → planuje, koordynuje, kontaktuje się z różnymi ludźmi, reaguje na opóźnienia, zmiany, kryzysy… i kończy dopiero jak impreza się odbędzie.
  - - - va application service
        
        Application Service:
        
        przyjmuje komendę,
        
        ładuje agregat,
        
        woła jego metody,
        
        zapisuje stan, publikuje eventy.
        
        SagaProcessor:
        
        przyjmuje event,
        
        ładuje instancję Sagi (jej stan),
        
        wywołuje metody Sagi (np. onUserRequestedHumanAgent),
        
        zapisuje stan Sagi,
        
        wysyła komendy do innych serwisów / agregatów.
        
        jest event-driven, zarządza stanem procesu, a nie stanem domeny.
- - - - event is sent to many subscribers, and indicates sth that has happened, not the next step
      - past tense verb phrase
      - Event – fakt (nieodwracalny)
        To jest coś, co się wydarzyło.
      - komenda nie zmienia stanu, event zmienia stan, stan jest efektem ubocznym eventu
  - - - zawierają struktury nieodpowiednie do prezentacji – spadek wydajności spowodowany pobieraniem z bazy i przesyłaniem, nadmiarowych danych
      - agregowane w nich obiekty mogą zostać pobrane poprzez mechanizm Lazy Loading, który w przypadku danych przekrojowych powoduje pojawienie się zjawiska „n+1 Select Problem” – drastyczny problem z wydajnością, który jest w większości przypadków niedopuszczalny
      - Agregaty z definicji są hermetyczne
      - posiadają metody biznesowe, które nie mają sensu w warstwie prezentacji
- - - - validations
        
        checks that input makes sense and objects are properly suited for further actions.
      - consequences
        
        initiating some action that will change the state of the world
      - derivations
        
        figuring out some information based on information we already have
        
        usually only to support validation or consequences
  - - - Another characteristic of this kind of application is that is an event sourced application, that is all updates to the display state are made through event objects that can be stored and queued.
      - The application is primarily a reporting application that gives users real time information about the state of something. It is an active application, in that the users have a lot of control about what kinds of things they are looking at they're able to drill down in particular areas and generally manipulate their display; however it is still, at least primarily a read-only application.
      - Taking these two characteristics together, and you can see that there's no need for a database to save the in-memory state of the display.
    - - firstly the application is very fast since there's no disk access involved as people manipulate the system.
      - Secondly all the complexities of mapping between in-memory and database are removed, which allows people to build a good domain model geared towards the display needs and never worry about persisting it
- - - - W architekturach opartych na rozwiązaniach ORM widujemy
        podejścia, w których wybrane dane z encji zwracanych przez
        bibliotekę/framework ORM zostają przepakowane do DTO. Tego
        typu podejście, owszem redukuje ilość danych przesyłanych
        do zdalnych klientów, ale wciąż na serwerze aplikacyjnym dochodzi do „rozbłysków” pamięci spowodowanych pobieraniem
        zbędnych danych.
    - - Wydajnościowo osiągniemy zdecydowanie lepsze wyniki niż
        w poprzednim podejściu, jednak możemy zastanowić się nad
        sensownością uruchamiania tych zapytań poprzez połączenia
        zestawione w trybie READ-WRITE, skoro wystarczające jest połączenie w trybie READ (chodzi tu o tryb działania połączenia do bazy danych, a nie o nazwy stosów w CqRS). Tego typu obiekty DTO nie są obarczone mechanizmem śledzenia zmian (Dirty Checking), mechanizmem Lazy Loadingu ani wsparcia dla zapisu kaskadowego.
    - - Jeżeli już decydujemy się na pobieranie poszczególnych kolumn
        z bazy, to dlaczego nie użyć czystego SQL zamiast konstrukcji
        języka zapytań mapera? Dodatkowo skoro wiemy, że w pewnych
        miejscach pobieramy dane jedynie do odczytu, to być może warto zestawić osobną pulę połączeń z bazą - połączeń read-only. W takim wypadku warto użyć lekkiego mapera typu myBatis,
        który mapuje Result Set na paczki danych (DTO), a nie na obiekty biznesowe służące do wykonywania operacji biznesowych
    - - Separację możemy poprowadzić jeszcze "głębiej" i dokonać
        projekcji modelu domenowego, który utrzymujemy w III postaci normalnej do postaci płaskiej, odpowiedniej do odczytu.
        Projektując Widoki, zmieniamy myślenie w stylu „co będziemy zapisywać” na myślenie w stylu „co będziemy odczytywać”.
        Pozwala to na projektowanie dedykowanych do szybkich odczytów struktur. Można traktować je jako projekcje modeli domenowych na potrzeby wydajnych odczytów. Być może potrzebujemy więcej niż jednej projekcji danego modelu domenowego. Pozwoli to uniknąć klauzul JOIN, które pojawiają się w nieturlany sposób, gdy odczytujemy dane z Modelu Domenowego.
    - - Być może powyższe rozwiązania wciąż nie przynoszą zadowalających wyników wydajnościowych. Możemy wówczas zaprojektować osobne modele do odczytu przygotowane do skalowania poziomego. Rozwiązaniem mogą okazać się osobne modele oparte np. o Shredding danych. Natychmiast pojawia się pytanie o odświeżanie danych w tego typu modelach. Co w sytuacji, gdy w Write Modelu (modelu domenowym) nastąpi np. zmiana danych produktu? Wprowadzamy techniczne Listenery zdarzeń domenowych, których zadaniem będzie uaktualnianie Read Modeli.
  - - - Zasada #2: ZMIANA read modelu ≠ zmiana eventów.
        Eventy są API domeny.
        Read modele to tylko indeksy.
      - Zasada #1: Read modele są jednorazowe i wyrzucalne.
        Read modele nie są źródłem prawdy i NIE muszą być migrowane 1:1 jak write modele.
        
        Zamiast tego:
        
        możesz je zresetować,
        
        możesz zrobić nową wersję obok starej.
        
        możesz je przebudować,
    - - Strategia 1 — „Additive-only” (najczęstsza, najlepsza)
        
        To znaczy:
        
        handler projekcji zaczyna je wypełniać,
        
        ale stare kolumny nadal są obsługiwane.
        
        dodajesz nowe kolumny,
        
        NIGDY nie robisz:
        
        usuwania kolumn,
        
        zmiany typu kolumny w miejscu (bez compat layer).
      - Strategia 2 — „Side-by-side read model” (v1 i v2 jednocześnie)
        
        Kiedy ją stosować?
        
        zmieniasz strukturę read modelu fundamentalnie (np. MessagesView → paginowane nested threads).
        
        nie da się zrobić ALTER TABLE,
        
        potrzebujesz tymczasowej migracji klientów.
      - Strategia 3 — „Full rebuild” (czyli DROP + REBUILD ze streamu)
        
        Używasz jej, gdy:
        
        read model się rozjechał,
        
        read model jest ogromny i trzeba z :fire: zrobić porządek,
        
        zmieniasz algorytm liczenia,
        
        zmieniasz sposób reprezentacji danych,
        
        zrobisz rok później wersjonowanie eventów i chcesz odbudować stan z nich.
        
        Flow:
        Stawiasz nową tabelę (np. messages_new)
        Uruchamiasz joba:
        consumer zaczyna czytać eventy od początku Kafki (offset 0),
        buduje read model od zera
        Po zakończeniu re-build’u robisz:
        ALTER TABLE ... RENAME
        odłączasz stary read model