102. State Obsession - EDA /Anti/Patterns
W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że "coś się w bazie zmieniło". Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu. State Obsession to sytuacja, w której zamiast faktów takich jak EmailConfirmed czy PersonalDocumentVerified, Twój system wypluwa generyczne UserUpdated. Na pierwszy rzut oka wygląda to na ułatwienie, ale w praktyce to prosty przepis na wyciek szczegółów implementacyjnych i utratę intencji użytkownika. Zapraszam na stronę https://bettersoftwaredesign.pl, gdzie znajdziesz jeszcze więcej materiałów.
W sumie szukam miejsc czy też jakiejś sytuacji, z których właśnie takie zdarzenia Updated, changed, wylatują. I tak mi przychodzą na myśl właśnie takie powody typu niedoeksplorowana domena de facto. Zrobienie właśnie takiego, wiesz, crowdsourcingu, tak jak tutaj opowiadasz, legacy. Z tego coś wyskakuje. Albo ta wspomniana przez ciebie kawka. Popularnym trendem jest właśnie twierdzenie, że możemy sobie zacząć wdrażanie architektur opartych na zdarzeniach i to właśnie przez Confluent Kafka jest bardzo promowane, chociaż teraz trochę mniej. Jak byłem na Kafka Summit w zeszłym roku, to już faktycznie podkreślali wartość jakości danych, chyba się zorientowali, że już nie tędy droga. Ale przez bardzo długi czas było promowane to, że zapnijmy sobie te CDC, czyli te tzw.
Change Detection Capture, czyli większość baz danych relacyjnych i nie tylko, ma taką możliwość, że możemy nasłuchiwać na każdy insert, każdy update, każdy delete w naszej tabeli i opublikować takie zdarzenie właśnie dodano, zaktualizowano, usunięto. I Kafka bardzo fajnie technicznie to pozwala zautomatyzować z takimi narzędziami jak Divisium, Kafka Connect. Jako narzędzie jest to super, bo faktycznie jeżeli to sobie wepniemy, skonfigurujemy, same dane się będą propagować. Tylko, że to nie jest tędy droga, bo to jest dokładnie ten sam problem jak mówisz o legacy, czyli że tylko i wyłącznie dostaniemy zdarzenia typu dodano, zaktualizowano, usunięto. Co gorsza, Te wszystkie narzędzia Change Detection Capture zapinamy na konkretne tabele, więc jak wiemy zwykle w tego typu systemach jedna zmiana wyzwala zmiany w kilku tabelach i zamiast znowu mieć jedno zdarzenie, że biznesowo się coś wydarzyło dostaniemy na tą naszą szynę tam pewnie z 3 razy, tyle ile mamy tabel, tyle dostaniemy zdarzeń updated.
Nikt się raczej w cyrku nie śmieje, kto próbuje to skorelować i zrozumieć, co się dzieje. Aż mnie w tym momencie stanął przed oczami kilka projektów, w których ostatnio miałem okazję uczestniczyć. Zastanawialiśmy się właśnie nad zapięciem Kawki, Dibizjum, żeby przechwytywać pewne zmiany, ale okazało się, że zrozumienie biznesowego znaczenia tego, co oznacza ta zmiana, nie tędy droga. Łatwiej będzie to jednak spotkać się z biznesem i chwileczkę porozmawiać, niż robić inżynierię wsteczną, bo to... Czym de facto jest ta zmiana twojego rekordu? Jest 17 tabel dalej. Dokładnie, dokładnie. No i to są bardzo fajne narzędzia i technicznie może nam to bardzo ułatwić tego typu użycie właśnie CDC, Kafka czy też innych szyn, które mają wsparcie tego CDC. Tylko jeżeli i tak musimy skorzystać z tych takich wzorców typu Outbox Pattern, jeżeli byśmy sobie mieli taką tabelę, do której wrzucamy te nasze zdarzenia, które coś mówią biznesowo i na tą tabelę sobie zapięli takie CDC, no to to jest naprawdę bardzo fajne techniczne rozwiązanie publikowania tych wiadomości dalej i zapewnienia
Pokazano wszystkie 3 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.
W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że "coś się w bazie zmieniło". Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.
State Obsession to sytuacja, w której zamiast faktów takich jak EmailConfirmed czy PersonalDocumentVerified, Twój system wypluwa generyczne UserUpdated. Na pierwszy rzut oka wygląda to na ułatwienie, ale w praktyce to prosty przepis na wyciek szczegółów implementacyjnych i utratę intencji użytkownika.
Zapraszam na stronę https://bettersoftwaredesign.pl, gdzie znajdziesz jeszcze więcej materiałów.