Better Software Design

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.

W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami.

W tym odcinku rozmawiamy z Michałem między innymi o:

• bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",
• odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,
• sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,
• wykorzystaniu USM w projekcie,
• różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,
• sposobach prowadzenia warsztatu analitycznego.

Materiały dodatkowe:

• It's All in How You Slice, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story Mappingu
• The New User Story Backlog is a Map, drugi po artykule istotny wpis Pattona na temat problemów z historyjkami
• User Story Mapping: Discover the Whole Story, Build the Right Product, książka Jeffa z 2012 roku, przedstawiająca technikę User Story Mappingu
• Story Map Concepts oraz Agile Story Essentials, krótkie i rzeczowe podsumowania pokazujące zasadę działania USM

Polecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.

Zapraszam!

Stres w pracy nie jest rzadkim zjawiskiem. Pozostawiony sam sobie przez dłuższy czas, może zacząć wyrządzać nam więcej szkód, w tym doprowadzić do syndromu wypalenia zawodowego.

O tym jak może się objawiać wypalenie w naszym codziennym życiu, jak można sobie z nim radzić i jak reagować, gdy problem zaczyna dotykać osoby w naszym otoczeniu - o tym wszystkim rozmawiamy dziś z Olą Kunysz. Bez technologii i architektury, ale o własnych doświadczeniach z wypaleniem w kontekście branży IT.

Materiały dodatkowe:

• The Burnout Index, darmowy test Yerbo wspomagający określenie poziomu ryzyka zagrożenia wypaleniem,
• Test BAT12, prostszy test w języku polskim,
• Nie wypalaj się! Jak żonglerka może uratować pracowników IT?, prezentacja Oli na TedX Koszalin
• Ola@Instagram, profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym

Eventy stanowią naturalny sposób komunikacji w systemach rozproszonych. Jednak przesyłanie i dalsze przetwarzanie zdarzeń z jednego systemu do drugiego zazwyczaj wymaga określonej infrastruktury i wprowadza do systemu nowy rodzaj złożoności. Zawodność przesyłania danych, unikanie wielokrotnego przetwarzania tych samych wiadomości, zapewnianie kolejności ich przetwarzania czy odpowiedniej wydajności całej aplikacji - to tylko niektóre z czekających tu wyzwań.

Dziś zapraszam na rozmowę o message brokerach i event-streamingu. Wraz z dzisiejszym gościem, Piotrem Gankiewiczem, rozmawiamy między innymi o:

• różnicach pomiędzy message-brokerami a platformami do event-streamingu,
• wykorzystywanej w obu przypadkach terminologii,
• zrównoleglaniu procesów i zapewnianiu odpowiedniego porządku przetwarzania pochodzących ze strumieni zdarzeń.

Zapraszam!

Materiały dodatkowe:

• Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, Martin Kleppmann, 2015
• Distributed Systems lecture series, playlista materiałów na temat projektowania systemów rozproszonych
• Building a Distributed Log from Scratch, seria artykułów na temat tworzenia systemów rozproszonych
• The Consistent Hash Exchange, artykuł na temat opisywanego w odcinku algorytmu przypisywania konsumerów w RabbitMQ
• Ordering Distributed Events, artykuł Vaidehi Joshi na temat porządkowania zdarzeń
• Distributed Systems: Time and order, teoria porządkowania w systemach rozproszonych
• You Cannot Have Exactly-Once Delivery

Zapraszam także do odwiedzenia:

• Iggy.rs, strona domowa projektu Iggy
• Piotr@Github
• Piotr@X / Twitter

Encje domenowe to obok Value Objectów jeden z podstawowych wzorców implementacyjnych Domain-Driven Design. Mogą działać zarówno samodzielnie, jak i być częścią innych struktur, np. agregatów. Ale czym właściwie są encje i co odróżnia je od pozostałych wzorców taktycznego DDD?

W telegraficznym skrócie encje to obiekty domenowe posiadające ściśle określoną tożsamość, które z jakiegoś powodu muszą być śledzone na przestrzeni czasu. Gościem dzisiejszej rozmowy jest Kamil Grzybek, który pojawił się już w Better Software Design przy okazji rozmów o modularyzacji monolitu czy testowalności oprogramowania.

W tym odcinku rozmawiamy między innymi o:

• przeznaczeniu wzorca Entity,
• różnych metodach nadawania tożsamości obiektom,
• podziałach encji względem cykli życia w domenie,
• różnicach pomiędzy encjami a agregatami czy Value Objectami,
• mapowaniu encji domenowych na encje bazodanowe.

Zapraszam!

Materiały dodatkowe:

• Implementing Domain-Driven Design, rozdział 5 poświęcony encjom domenowym
• What Is the Hi/Lo Algorithm?, artykuł na temat algorytmu Hi/Lo do generacji identyfikatorów
• Entity Identity vs Database Primary Key
• Modular Monolith with DDD, repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych

W greenfieldzie, który jeszcze nie dotarł do środowiska produkcyjnego zazwyczaj wszystko jest dość proste. Nawet przy zupełnej zmianie koncepcji w najgorszym razie można postawić bazę danych czy środowisko od zera. Jednak gdy system działa na produkcji, trzeba wprowadzać w nim głębsze zmiany, a do tabel w bazie przywiązana jest nie tylko aplikacja, sytuacja trochę się komplikuje. Dziś zapraszam na rozmowę o wprowadzaniu EventSourcingu do projektu, na przykładzie prawdziwego systemu obsługi cashflow.

Moim gościem jest Łukasz Reszke, pracujący na co dzień właśnie przy projektach opartych o event-store i EventSourcing.

W tym odcinku rozmawiamy z Łukaszem między innymi o:

• praktycznym zastosowaniu EventSourcingu w projekcie z problemami u klienta,
• wdrażaniu EventSourcingowego modułu do aplikacji z istniejącą relacyjną bazą i danymi,
• publikacji eventów do pozostałej części systemu i rodzajach eventów,
• odczytywaniu danych ze zdarzeń, strumieniach i linkowaniu do nich zdarzeń.

Materiały dodatkowe:

• Working with RailsEventStore in Cashflow Management System, prezentacja Łukasza z konferencji wroc_love.rb 2023
• Eventsourcing Patterns: Migration Events in a Ghost Context, artykuł Mathiasa Verraesa o imporcie danych z systemów legacy do modelu opartego o zdarzenia
• Patterns for Decoupling in Distributed Systems: Summary Event, kolejny artykuł Mathiasa Verraesa, tym razem o emitowaniu zdarzeń zbiorczych
• Łukasz@X, profil Łukasza na X/Twitter

Wspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć tutaj.

Każdy kod zostanie przetestowany, wcześniej bądź później. Pozostają jedynie pytania na jakim etapie i przez kogo zostanie to wykonane i jaki będzie tego ostateczny koszt. Gdy aplikacja staje się złożona i tworzy ją wiele różnych komponentów, proces testowania może zacząć przysparzać pewnych trudności, choćby z odwzorowaniem odpowiedniego środowiska uruchomienia testów. I tu przychodzi z pomocą biblioteka Testcontainers.

Testcontainers to framework pozwalający testować aplikację w oparciu o kontenery Dockera z prawdziwymi zależnościami systemu. I choć pozornie brzmi to banalnie, narzędzie to oferuje szereg bardzo praktycznych i przydatnych rozwiązań, znacznie upraszczających cały proces testowania integracyjnego.

Moim gościem jest dziś Piotr Przybył, Software Gardener z wieloletnim doświadczeniem programistycznym, który o praktycznym wykorzystaniu Testcontainers w projektach wie naprawdę sporo.

W tym odcinku rozmawiamy z Piotrem między innymi o:

• częstych problemach z testowaniem kodu i jego jednostkach,
• możliwych podejściach do organizacji testów w piramidy, odwrócone piramidy, plastry miodu...
• zasadzie działania biblioteki Testcontainers i jej kluczowych konceptach,
• różnicach pomiędzy Testcontainers a innymi sposobami uruchamiania usług podczas testów,
• synchronizacji kodu testów opartych o Testcontainers z infrastrukturą produkcyjną.

Zapraszam!

Materiały dodatkowe:

• Testcontainers Getting Started, dokumentacja omawianej w odcinku biblioteki
• Katalog modułów, dostępne gotowe kontenery z prekonfigurowanymi usługami
• Testcontainers Workshop, repozytorium na Githubie z przykładowym kodem krok-po-kroku
• Integration tests are needed and simple, prezentacja Piotra o testach integracyjnych z użyciem TC z konferencji Devoxx UK 2023
• Testcontainers: needed, simple, powerful, dłuższa, niemal 3 godzinna prezentacja z Devoxx z Belgii
• Wpisy o Testcontainers, blog Piotra o oprogramowaniu, nie tylko o testowaniu

Czy nieczytelny, trudno nierozszerzalny i na dodatek zduplikowany kod może być dobry? Co więcej, nawet pożądany? Tak, jeśli w projekcie istotne są zupełnie inne drivery, np. w postaci oczekiwanej dużej wydajności systemu. Wówczas poświęcenie pewnych cech kodu na cześć innych wydaje się mieć dużo sensu.

Dziś zapraszam na rozmowę z Tomaszem Lelkiem, współautorem wydanej w ubiegłym roku w wydawnictwiem Manning książki "Software Mistakes and Tradeoffs: How to make good programming decisions". A rozmawiać będziemy właśnie o świadomym podejmowaniu decyzji, zwłaszcza w kontekście wydajności i optymalizacji systemu. Nie od dziś przecież wiadomo, że zbyt wczesna optymalizacja jest źródłem całego zła. Niestety wykonana zbyt późno też źródłem wszystkich kosztów...

Dzięki uprzejmości wydawnictwa Manning mam 2 kody uprawniające do darmowego pobrania książki Tomka "Software Mistakes and Tradeoffs: How to make good programming decisions" w formie ebooka. Zapraszam więc do podzielenia się historiami o optymalizacjach waszych systemów. Kody te trafią do dwóch osób, których zgłoszenia zostały wybrane przeze mnie jako najciekawsze i najbardziej pouczające dla Ciebie i/lub zespołu.

Termin przesyłania zgłoszeń mija z końcem 30 września 2023 roku, nadsyłać je można z użyciem formularza dostępnego na stronie https://forms.gle/o2rVAQHmwZuyP7y66

Temat tworzenia oprogramowania pod konkretne potrzeby biznesowe, we współpracy z ekspertami domenowymi pojawiał się wielokrotnie w podkaście. Ale jak tworzyć oprogramowanie w modelu open-source, które będzie wykorzystywane przez innych developerów i gdzie pojedynczy ekspert domenowy nie istnieje, bo trzeba dbać o wielu różnych klientów?

Jak tworzyć oprogramowanie rozszerzane następnie przez innych developerów, jakie techniki stosować, dlaczego to co w innym projekcie byłoby bad-practice tu może być dobrym rozwiązaniem - m.in. o tym będziemy rozmawiać dziś z Łukaszem Chruścielem. Łukasz od wielu lat pracuje w core-teamie open-source'owego frameworka e-commerce Sylius, a dodatkowo miliony pobrań poszczególnych pakietów tego kodu i wiele dużych wdrożeń w projektach będzie tu ciekawą perspektywą.

Zapraszam!

Materiały dodatkowe:

• Sylius Github, repozytorium projektu
• Profil Łukasza na Twitterze
• Rozterki i decyzje. Czego się nauczyliśmy projektując API Syliusa, prezentacja Łukasza z konferencji Boiling Frogs 2023, przy okazji której mogliśmy się spotkać i porozmawiać

Eventy świetnie pozwalają rozdzielać duże systemy na mniejsze części i i przenosić między nimi dane. Każda usługa może wówczas je przetwarzać w oparciu o własną logikę biznesową. Problem w tym, że propagacja danych w systemie jest dość prosta, ale ich usunięcie już niekoniecznie...

O tym, w jaki sposób możemy rozwiązywać problem przetwarzania danych prywatnych rozmawiam dziś z Oskarem Dudyczem. I choć skupiamy się przede wszystkim na architekturach zdarzeniowych, to w zasadzie wszystkie omawiane techniki można bez problemu zastosować również w innych systemach.

W tym odcinku razem z Oskarem rozmawiamy m.in. o:

• prywatności niektórych danych,
• usuwaniu danych vs utracie możliwości ich dalszego przetwarzania,
• strategiach "zapominania" o danych prywatnych w architekturach eventowych,
• czym jest i jak działa crypto-shredding, tombstoning czy scavenging,
• GDPR i o tym, o czym zwykle mało pamięta się w projekcie...

Materiały dodatkowe:

• How to deal with privacy and GDPR in Event-Sourced systems, prezentacja Oskara na omawiany w odcinku temat z konferencji Devoxx Greece
• Scalable User Privacy: Crypto Shredding at Spotify, prezentacja Brama Leendersa na temat przetwarzania danych prywatnych w Spotify
• GDPR - General Data Protection Regulation, zestaw regulacji na temat prywatności i ochrony danych prywatnych
• Tombstoning i scavening w EventStoreDB, fragment dokumentacji na temat sposobów usuwania zdarzeń

"Architekci muszę bez przerwy oceniać cechy architektury, aby upewnić się, że ciągle zapewniają one jakość i nie stają się antywzorcami..." Ten cytat z książki "Building Evolutionary Architectures: Support Constant Change" autorstwa Neala Forda, Rebeki Parsons i Patricka Kua dotyczy jednego z fundamentów architektury ewolucyjnej, czyli tzw. funkcji dopasowania - Fitness Functions.

Funkcje te pozwalają konkretnie ocenić dopasowanie architektury oprogramowania względem postawionych wymagań i podejmować świadome decyzje odnośnie wprowadzania zmian. Czym są wspominane tu funkcje, jak można je definiować i weryfikować, a także czym jest architektura ewolucyjna, o tym rozmawiamy z moim dzisiejszym gościem, Sebastianem Buczyńskim.

Zapraszam!

Materiały dodatkowe:

• Building Evolutionary Architectures: Support Constant Change, Neal Ford, Rebecca Parsons, Patrick Kua, 2017
• Building Evolutionary Architectures, prezentacja Rebeki Parsons, Neala Forda i Jamesa Lewisa z konferencji GOTO 2023
• Evolutionary Software Architectures, prezentacja Neala Forda z Voxxed Days
• Evolutionary Architecture from an Organizational Perspective, artykuł jednego z gości Better Software Design, Radka Maziarki na temat dopasowania architektury do przedsiębiorstwa