Pod wpływem postu @Koziołek nasunęło mi się pytanie jak od strony kodu działa w banku wykonanie przelewu? W książkach jest to właśnie taki uproszczony przykład - zakładamy transakcję, odejmujemy od jednego, dodajemy do drugiego i w zależności od powodzenia commitujemy lub robimy rollback. A jak to wyglada w realnym swiecie? Móglby ktoś (może @Koziołek) jakos szerzej to opisać i wrzucić jakieś przykładowe kody jakby to mogło być realizowane?
- Rejestracja:prawie 21 lat
- Ostatnio:prawie 5 lat
- Rejestracja:ponad 12 lat
- Ostatnio:7 miesięcy
- Postów:6610
1
jeśli jest to przelew wewnętrzny to tak to mniej więcej wygląda (+ sprawdzanie czy są środki dostępne), przy przelewach zewnętrznych w grę wchodzą zewnętrzne serwisy jak ELIXIR
8
@goodfather: to zależy od banku. W najprostszym modelu masz mniej więcej taki proces:
Po stronie obciążenia:
- Zlecenie przelewu przez uprawnionego użytkownika/automat (np. przelewy stałe, polecenia zapłaty itp.)
- Sprawdzenie, czy na koncie jest wystarczająca ilość środków i:
- nie ma środków, to odrzucamy zadanie albo,
- nie ma środków, to zakładamy blokadę i generujemy ostrzeżenie dla klienta albo,
- są środki, to zakładamy blokadę.
- Wygenerowanie dokumentu przelewu
- przesłanie dokumentu do systemu rozliczeniowego i księgowego.
- „obciążeniowe” zdjęcie blokady (zdjęcie blokady powoduje obciążenie rachunku).
Po stronie uznania:
- Pojawia się polecenie uznania rachunku,
- sprawdzenie, czy rachunek może być uznany (istnieje, czy są blokady itp.) → możliwe odrzucenie, co wiąże się z wygenerowaniem storno dla strony obciążonej.
- wygenerowanie zdarzenia księgowego → uznanie konta.
- uznanie na rachunku.
Po stronie banku w obu przypadkach potrzebne są odpowiednie operacje księgowe zgodnie z zasadą podwójnego zapisu. I tu właśnie leży „realna magia” operacji na kontach bankowych. Każda taka operacja przechodzi przez księgę rachunkową banku, gdzie pozostaje po niej ślad. Co ciekawe w księdze tej nie ma rachunków klientów, a konta księgowe, które odpowiadają „kierunkom” ruchu pieniądza. W ten sposób bank wie, ile pieniędzy przyjął i ile wysłał w świat (tzw. konta drogi). Ile było operacji przewalutowania (konta w walucie obcej) albo ile wpłacono/wypłacono w okienku (konta materiałowe).
Do tego dochodzi rekoncyliacja, czyli wzajemne sprawdzenie zapisów pomiędzy kontami księgowymi, ale też np. pomiędzy bankiem, KIR-em i NBP (tak jak ma to miejsce w ELIXIRze).
Jeżeli do czegoś miałbym to porównać, to najbliżej jest do event sourcingu. Przy czym ES jest to taki dość prymitywny mechanizm.
edytowany 1x, ostatnio: Koziołek
Zobacz pozostały 1 komentarz
Koziołek
@hauleth: na braku odporności na zmiany stanu wprowadzane z zewnątrz. Na braku mechanizmu storno na najbardziej abstrakcyjnym poziomie (technicznie też to jest upierdliwe). Przy czym ES „robi robotę” w zakresie ilości przechowywanych danych i dostępu do danych historycznych.
yarel
Hmm, storno dla zdarzeń czy w innym sensie? Bo jak dla zdarzeń, to pewnie równie dobrze można powiedzieć, że brak mechanizmu dla zacommitowanej transakcji w bazach relacyjnych. Chyba, że coś innego kryje się po brakiem mechanizmu storno?
Koziołek
Storno w księgowości wiąże ze sobą dwa zapisy. W ES każdy zapis jest całkowicie niezależny i bez sprawdzenie wszystkich zapisów późniejszych nie możesz powiedzieć, że dany zapis jest anulowany.
yarel
Ok, wydaje mi się, że rozumiem o co Ci chodziło z tą prymitywnością ES. Trudno oczekiwać czegoś wyszukanego, bo ES jest (z mojej perspektywy) mechanizmem technicznym, zaś operacja storno elementem mechanizmu biznesowego z dobrze zdefiniowanymi regułami. W warstwie "technicznej", "anuluj zdarzenie X" ma dość proste implikacje (pomiń zdarzenie), ale co to znaczy dla "biznesu", to nie wiadomo, dopóki biznes nie zdefiniuje. Trzeba pamiętać, że warstwa techniczna sama nie rozwiąże problemów biznesowych :-)
hauleth
@Koziołek: zgadzam się z @yarel, że w tym wypadku to ES może dalej być bazą techniczną, natomiast na tym możesz zbudować logikę biznesową, która już takie informacje będzie zawierała.