
Hosted by Mariusz Gil · PL

Zanim pójdziecie w mikroserwisy, upewnijcie się, że wasze granice są poprawne. W modularnym monolicie pomyłkę naprawicie jednym refaktorem w IDE. W rozproszonym systemie zapłacicie za to zmianami w infrastrukturze i bazach danych... Między innymi właśnie to warto zapamiętać z rozmowy z Damianem Dziaduchem, który podzielił się historią refaktoryzacji pewnego smutnego monolitu.

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.

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

Better Software Design zaczęło się w 2020 roku od tematów związanych z Domain-Driven Design, gdzie często z Kubą Pilimonem zagłębialiśmy się w kolejne wzorce i przykłady. Po kilku latach wspólnie z Kubą wracamy do tej tematyki, aby sprawdzić, jak zmieniło się nasze postrzeganie Domain-Driven Design i pracy architekta w świecie, który przyspieszył do prędkości mierzonych w tokenach na sekundę. A rozmowę zaczynamy od pytania Kuby, jednego ze słuchaczy podcastu, które pojawiło się przy okazji zbliżającego się odcinka specjalnego z okazji 100 odcinków Better Software Design.

Od ostatnich odcinków minęło trochę czasu, ale świat IT nie stał w miejscu – wręcz przeciwnie, przyspieszył tak, że momentami trudno nadążyć. Dlatego w tym odcinku, wspólnie z Łukaszem Szydło i Marcinem Markowskim, próbujemy po prostu głośno zastanowić się, co tak naprawdę dzieje się z pracą architekta oprogramowania i ogólnie architekturą software'u w dobie wszechobecnego Generative AI.Gdy kolejne modele wychodzą w coraz szybszym tempie, w zasadzie trochę trudno rozmawiać o tym, jakie 10 narzędzi zmieni Twoje życie architekta, z których warto korzystać już teraz. Zamiast tego usiedliśmy, żeby porozmawiać o naszych spostrzeżeniach i obserwacjach z placu boju. AI wpędza nas po trochu w pułapkę: kod powstaje błyskawicznie, ale nasze ludzkie moce przerobowe do jego czytania i weryfikacji pozostają w zasadzie bez zmian. Czy przez to nie zmieniamy się powoli w redaktorów kodu i czy Code Review nie stanie się zaraz największym wąskim gardłem w naszych projektach? Ale Code Review jest tylko jednym z etapów procesu Software Development Lifecycle, na którym widać wpływ narzędzi AI.Ogłoszenie!Już niedługo, bo 17 lutego, będziemy mogli się spotkać na otwartym warsztacie DevHours: Fullstack x EventStorming, który mam przyjemność współorganizować z Capgemini. Jeśli interesujesz się oprogramowaniem i chcesz podnieść swoje umiejętności w projektowaniu software'u, zapraszam do rejestracji.

W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem? Czy w każdym procesie biznesowym potrzebujemy dokładnie tego samego, silnego poziomu spójności i czy sztywny podział na agregaty zawsze idealnie odzwierciedla dynamiczną naturę problemu, który modelujemy?Okazuje się, że możemy podejść do tego zagadnienia w bardziej elastyczny sposób. W tym odcinku, wraz z moim gościem, Pawłem Pacaną z firmy Arkency, dokładnie przyjrzymy się koncepcji Dynamic Consistency Boundary. Porozmawiamy o tym, jak można myśleć o spójności nie jako o statycznej, raz ustalonej granicy, ale jako o koncepcji, która dopasowuje się do kontekstu konkretnej operacji biznesowej.W tym odcinku usłyszysz między innymi o:trudnościach w projektowaniu i długoterminowym utrzymaniu agregatów w systemieDynamic Consistency Boundary i czym ten wzorzec różni się od klasycznego podejścia z agregatemtagowaniu i linkowaniu zdarzeń pomiędzy strumieniamiwymaganiach dla event-store, aby stosowanie Dynamic Consistency Boundary było w ogóle możliwe pułapkach, na które należy zwrócić szczególną uwagę, by wykorzystanie DCB nie stało się problemMateriały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.

Ponad 2000 osób w 500 zespołach, 3000 różnych mikroserwisów i kilkaset tysięcy eventów na sekundę - skala Allegro zawsze robi wrażenie. Jak w tym wszystkim wdrożono architekturę mikrofrontendów, która pozwala sprawnie łączyć różne mikroserwisy i tworzyć podstrony największego w Polsce e-commerce'u prosto z panelu?W drugiej części rozmowy o mikrforontendach, Bartosz Gałek, Principal Engineer w Allegro, uchyli rąbka tajemnicy i przedstawi trochę technikaliów. W tym odcinku usłyszysz między innymi o:skali systemu, z jaką mierzą się zespoły developerskie Allegrowybranych metrykach zapewniających observability systemu od strony frontendowejprojektowaniu optymalizacji i zapewnianiu dużej wydajności systemuprojektowaniu stron portalu z użyciem komponentów i wprowadzaniu nowych funkcjonalności na produkcjęstreamingu HTML-astopniowej migracji monolitu do architektury mikroserwisowejDzięki Bartkowi mamy możliwość zajrzeć za kulisy i zobaczyć co się dzieje "pod maską" Allegro, gdy odwiedzasz przykładowo podstronę interesującego Cię produktu. I dlaczego, dzięki stosowanym rozwiązaniom i optymalizacjom, jest to tak wydajne...Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.

Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.Sieć ze swojej natury bywa zawodna, przerwa w dostarczaniu wiadomości, czy też dostarczanie ich do konsumentów w losowej kolejności nie są sytuacjami czysto hipotetycznymi. Wcześniej czy później taka sytuacja przydarzy się w systemie, pytanie brzmi tylko "kiedy"...Michał Ostruszka w dzisiejszej rozmowie zarysowuje kilka wzorców w kwestii gwarancji dostarczania wiadomości, które obok Outbox Pattern warto mieć w swojej architektonicznej skrzynce z narzędziami. Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.

Termin "microservices architecture" w ostatnich latach był odmieniany przez wszystkie możliwe przypadki. Przeważnie jednak ten styl architektoniczny przewijał się w kontekście rozwiązań backendowych i wyciągania z monolitów fragmentów jego funkcjonalności. Rzadko jednak mówiło się o projektowaniu rozwiązań frontendowych w tego rodzaju systemach...Netlifx, Amazon, Spotify czy Uber - te firmy przychodzą z pewnością na myśl jako przykłady popularnych wdrożeń mikroserwisów. W Polsce zdecydowanie jest to Allegro, które dokonało migracji z monolitycznego systemu PHP do właśnie takiej architektury i innych technologii.Tomasz Ducin i Bartosz Gałek, Principal Engineer w Allegro, zaglądają "pod maskę" największego portalu ecommerce w Polsce, aby porozmawiać na temat architektury microfrontendów.Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.

Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.Temat samych testów kontraktowych pojawił się już w podkaście, w odcinku "O testowaniu kontraktowym z Rafałem Maciakiem". W dzisiejszej rozmowie, wraz z Jackiem Milewskim, uzupełniamy to podejście o aspekty praktyczne, aby zabezpieczanie komunikacji pomiędzy serwisami nie stało się szybko długiem technicznym, którego utrzymanie będzie kosztować wszystkie zespoły czas i niepotrzebne nerwy.Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.