O tu tu, zapisuję również moment w którym wprowadzono zmianę. I pod tym mam raczej ułomny kod który jakoś odtwarza historię i nalicza składkę ze zmianą wielkości. Obawiam się, że robię coś nie według sztuki.
Dobra, już kumam. IMHO lepiej byłoby to zrobić czysto rasowo na zdarzeniach - mniej pitolenia z wyciąganiem tych danych. Oraz: porównując ten system do bardzo uproszczonego banku, to biorąc kredyt hipoteczny masz listę zdarzeń debited na następnych 20 lat i dorabiasz do nich zdarzenia credited. Jakoś bardziej mi się to trzyma kupy (ale to mi, nie jestem nieomylną wyrocznią itp, itd).
Mógłbyś się nawet pokusić o generowanie zdarzeń zmiany wysokości deklarowanych składek, żeby już wiedzieć wszystko i zawsze 
W takim razie przygotuje kolejny prototyp. Z bardziej koszernym modelem.
Nadal zastanawia mnie jak obsłużyć różne “plany” składek. Oraz to jak się zmieniają w wysokości i relacji do członków.
Przynajmniej nauczyłem się trawersować historię.
Masz na myśli to, że niektórzy chcą np płacić kwartalnie? Debited księgowane raz na kwartał. Logika decydowania o tym kiedy komu kwartał się zaczyna musi być zależna od daty rozpoczęcia członkostwa.
Rozważ dwa scenariusze:
- podwyższenie składki dla wszystkich
- zmiana planu ze “zwyczajnej” na “studencką” dla jednego konta
1 polubienie
Wychodzi na to, ze w systemie występuje zdarzenie „zmiana wysokości składki” wraz z agregatem opisującym aktualną wysokość składki.
W kwestii formalnej: kto tu jest do kroścset ekspertem domenowym!? iks-de
Moje trzy grosze:
Jeżeli powstanie taki system to będzie to infrastruktura krytyczna (ze względu na to jakie posiada dane).
O ile nie istnieje już gotowe do tego rozwiązanie to zgodnie z naszą niepisaną zasadą “infra nie służy do nauki i zabawy” chciałbym, żeby ten system był możliwie prosty.
Sparsowanie wyciągu z banku i wyświetlenie członkowi informacji o opłaconych składach jest wg mnie wystarczające.
Szkoda byłoby się też zakopać w developmencie.
Ale ja tego nie piszę, tylko moja rada, trzymam kciuki
1 polubienie
Co do składek:
Wynoszą one 100 zł. Jak ktoś wpłaca więcej to miło z jego strony.
Składka studencka wynosi 50 zł, ale w praktyce różnie wpłacają i tego nie opisują.
Kiedyś uznaliśmy, że możemy liczyć nadpłaty do 3 msc w przód, ale tak czy siak niektórzy zapłacili rok do przodu.
Niektórzy zapominają, a jak im się przypomni 5 razy to opłacą kilka składek do tyłu i kilka do przodu.
Daremne są moje próby przekonania wszystkich do płacenia składek regularnie, co miesiąc, z odpowiednim formatem opisu.
Obawiam się, że system, który opiera się na pełnej automatyzacji, a nie na ręcznych poprawkach i interpretacjach nie będzie działać.
Zasadą od poprzedniego autora systemu składkowego 
.
Najpewniej będę miał coś takiego dzisiaj. Ale bez obsługi SSO
Te rzeczy nie muszą się gryźć. Mając log wydarzeń możemy audytować zmiany wprowadzane przez automat. I tak samo jeśli coś jest wprowadzane ręcznie.
Niestety ciężko o sensowne i gotowe rozwiązania. Są całe systemy, a te częsta mają inne założenia i różną skalę. Dlatego chcę wydestylować obsługę samych skladek do osobnego komponentu.
Pytanie czy ręczne poprawki będą first-class-citizen czy trzeba będzie się doktoryzować z budowy systemu żeby je wprowadzić.
Pod tą zasadą kompletnie się podpisuję i dlatego w ogóle zabrałem głos w tym wątku. Bo odnoszę trochę wrażenie, że ten cały event-sourcing jest dużym eksperymentem (ktoś używał wcześniej chociaż tej biblioteki), a to jest ostatnie miejsce, w którym sugerowałbym eksperymenty. No ale tak samo jak napisał @amadeusz, nie piszę do tego na razie żadnego kodu więc to tylko sugestia.
To jeszcze moje trzy grosze: raz jeden w życiu zdarzyło mi się pisać system, który przetwarzał płatności (reklamy w internecie pokazywaliśmy i kasowaliśmy reklamujących). Nie wiedzieliśmy wtedy o istnieniu event sourcingu i nie mogliśmy użyć tej metodologii, więc ją wynaleźliśmy sami.
Uważam, że byliśmy na to skazani z następujących powodów:
- tylko sytuacja, w której jesteśmy w stanie prześledzić wszystkie operacje, które miały miejsce gwarantuje, ze możemy ustalić co spieprzyliśmy.
- chodzi o pieniądze, o które łatwo się pokłócić - punkt powyżej jest tym bardziej istotny.
- jeśli jest potrzeba poprawienia jakiś zapisów, to wystarczy wygenerować zdarzenie „ręczna poprawka” i problem jest załatwiony.
Z powyższych względów uważam, że event sourcing jest słusznym rozwiązaniem problemu.
1 polubienie
Myślę, że wspaniałą zasadą jest transparentność przy takich projektach. I bardzo cieszy mnie wasze zaangażowanie. Póki to jest faza prototypów można (nie daj Boże) nauczyć się co działa, a co nie.
Wybór na event sourcing wpadł przez różne drobne sugestie innych członków. Jest to też mój wniosek analizując inne kody. Które obawiam się, że wymagają doktoryzowania na boku.
W sumie spójrzmy na przykłady:
Tabela będąca listą transakcji (bank actions)
Lista transakcji i przypisanie ich do użytkownika. Hardcoded typy składek
https://code.hackerspace.pl/enleth/kasownik/tree/web/webapp/models.py?id=6a5a6b96a536d52c7dc952bac8e1a8c24a4e81a9#n92
Mają nietrywialną obsługę typów składek i oczywiście log transakcji
Kolejny log transakcji
Nawet ladny model, który ma agregat listy transakcji (patrz balance)
To chce być całkiem generyczne. Też ma log transakcji i z nich wylicza balans, całkiem sporo logiki przy modelach
Kolejna lista transakcji, no i też sporo innych rzeczy dookoła.
2 polubienia
Zbierając te wszystkie informacje dochodzę do następujących wniosków.
Zadaniem systemu jest wykrywać anomalie i o nich informować. Jak również w prosty sposób na nie reagować. Ma pomóc znormalizować sposób płacenia składek w organizacji (długo terminowo).
Co nie jest ważne moim zdaniem, to przechowywać dane o transakcjach. Nie potrzebujemy wszystkich szczegółów po ich przetworzeniu. To co jest ciekawe dla nas, to informacja czy przetworzyliśmy daną unikalną transakcję. Oraz co z niej wynika: czy ktoś zapłacił składkę, albo czy nie płacimy za dużo za sprzątanie.
Szczegóły transakcji siedzą sobie bezpiecznie w banku i zawsze możemy po nie sięgnąć po unikalnym id transakcji.
To moja obserwacja pod kątem bezpieczeństwa danych.
W ogóle, co dokładnie przez to rozumiesz?
Chodzi mi głównie o to, żeby wprowadzanie zmian było możliwie proste i nie skończyło się tak, że możliwość wprowadzenia jakiegoś rodzaju zmiany nie była przewidziana przez co trzeba się będzie wgryzać w szczegóły implementacyjne.
Wszystkie tego typu zmiany będą “first class citizen” jeśli będą zdarzeniami.
W między czasie, edukuje się i to mocno. Podoba mi się ten moment 
No i ten talk
Ej o co chodzi w tym wątku - przecież Stripe to załatwia o czym piszecie.
edit: chyba że napisanie systemu składkowego jest również projektem 4fun
Możesz rozwinąć? Jak wygląda pełne wdrożenie Stripe w tym temacie? Ile kosztuje? Jak wygląda kwestia prywatności w porównaniu do zwykłych przelewów?
1 polubienie
Postaram się nieco odkopać ten temat. Ale użycie Stripe może też pomóc stworzenia jakiegoś adaptera do API. Wtedy jak ktoś ma problem z używaniem tej zamkniętej usługi, to może wykorzystać inny payment processor. W sumie daje też to lepszą idee jak podzielić architekturę systemu.
1 polubienie