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
Produkcja Polskie Towarzystwo Astronomiczne Better Software Design to podcast o projektowaniu oprogramowania. Wraz z moimi gośćmi rozmawiamy o architekturze, szczegółach implementacyjnych i wyzwaniach z tym związanych. Jeśli interesujesz się tworzeniem oprogramowania, to ten podcast jest właśnie dla Ciebie. Zapraszam na odcinek. Cześć, Oskar. Cześć. Słuchaj, mam taki pomysł, aby w podcaście pojawiła się taka miniseria, no zobaczymy, czy będzie mini, bo temat, który chciałbym zaatakować, chyba taki mini nie jest, ale żebyśmy tak w każdym odcinku, tutaj będzie troszeczkę krótszy, wzięli na tapet jakiś konkretny problem ze świata eventowego.
Ale w świat już puszczę ten event taki zgrupowany z wszystkimi danymi. Tak, no zawsze każdy nasz design, według mnie, powinniśmy kilkukrotnie próbować challenge'ować z biznesem i rozmawiać z nim, żeby upewnić się, czy to, co my wymyśliliśmy jest prawdą. No zresztą... Ty sam wiesz najlepiej, że ten model, który nawet jeżeli stosujemy event storming, to nie jest ten sam model, który wyląduje w kodzie i bardzo często nawet nie byłoby dobrze, jakby on wylądował dokładnie w takiej samej formie, więc to jest coś, co zawsze jest gdzieś ten element translacji, który może zostać pewne rzeczy zgubione i dla mnie osobiście na przykład właśnie zaletą zdarzeń jest to, że
Jeżeli sobie nie zdajemy z tego sprawy, to jest ten najgorszy coupling w zasadzie. No to jeszcze możemy w sumie na koniec odesłać do książki Wladyka, Balancing Coupling in Software. Książka, która chyba w ogóle ostatnio robi trochę furory. Tak, wiem ile Wladik się nad nią męczył, więc bardzo się cieszę, że mu się udało ją skończyć. Czyli tak podsumowując, jeżeli zauważył w moim systemie faktycznie masę zdarzeń, ta proporcja się zmieniła, ta właściwość została zmodyfikowana, mam masę eventów typu updated, rename itd., to może to być sygnał, właśnie cierpię z tego dokładnie powodu, I być może tutaj pierwszym pomysłem powinno być wrócenie do tej deski kreślanskiej i zastanowienie się, co to znaczy biznesowo. Ja jeszcze dodam, że to jest też powiązane z wersjonowaniem kontraktów, ale ludziom się wydaje, że
Pokazano wszystkie 3 dopasowania. 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