101. Property Sourcing - EDA /Anti/Patterns
Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing. W tym odcinku rozmawiamy z Oskarem m.in. o tym: dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być" jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych
Jeżeli będziemy mieli kilka modeli odczytu, a zwykle Jeżeli używamy architektury opartą na zdarzeniach, to między innymi po to to robimy, czyli no nawet zmiana powiedzmy imienia. No to możliwe, że mamy model odczytu, który widzimy tam w rogu, który pokazuje kto jest zalogowany, że mamy model odczytu, gdzie jest lista użytkowników, że mamy dane do faktury. Tych miejsc jest naprawdę bardzo dużo. O tym możemy sobie na początku nie zdawać sprawy. No wiesz, taki nawet prosty przykład. Tutaj kiedyś w rozmowie z Piotkiem przybyłem, jak rozmawialiśmy właśnie o pewnych, powiedzmy, antypaternach w ogóle w programowaniu, gdzie pojawił się ten przykład, który Piotrek pokazuje na konferencjach z adresem, jako jest trudność w zamodelowaniu struktury adresu i jaką on ma zmienność. I tak pomyślę sobie, że na obsługę zmiany takiego adresu bym potrzebował pewnie z sześciu, siedmiu eventów, a później pewnie jeszcze w aplikacji ten adres jest użyty w iluś tam miejscach, to przemnożone razy liczbę zmian, liczbę eventów, liczbę hendlerów, które ten event muszą obsługiwać.
Pokazano wszystkie 1 dopasowanie. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.
Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.
W tym odcinku rozmawiamy z Oskarem m.in. o tym:
dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być" jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych