Better Software Design

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.