Better Software Design Mariusz Gil

Kierowanie strategicznym rozwojem projektu może przysparzać wielu wyzwań. Dzisiejszy gość, Radek Maziarka, przedstawia narzędzie Wardley Mappingu, które może być ciekawym wsparciem przy strategicznym wyznaczaniu kierunku rozwoju organizacji i produktu.

W tym odcinku Radek przedstawia m.in.
- czym są mapy Wardley'a,
- komu mogą okazać się przydatne w rozwoju produktu,
- jak Wardley Mapping może łączyć się ze strategicznym Domain-Driven Design,
- w jaki sposób można wykorzystać je do planowania prac rozwojowych (i nie tylko).

W architekturze mikroserwisowej często wykorzystuje się zdarzenia do wprowadzania asynchroniczności i zmniejszania couplingu pomiędzy poszczególnymi częściami systemu. Ale opieranie komunikacji w każdym możliwym przypadku o koncept eventu często doprowadza do powstania zupełnie nowych problemów, związanych np. z koniecznością wprowadzania jednoczesnych zmian w wielu różnych częściach systemu. Łukasz Szydło, gość dzisiejszego odcinka wprowadzi nas w temat autonomii zmian w takiej architekturze i wykorzystania różnych narzędzi do jej projektowania.

W dzisiejszym odcinku będzie można posłuchać m.in. o:
- autonomii wprowadzania zmian w architekturze mikroserwisowej,
- couplingu i decydowaniu, kiedy chcemy się go pozbywać z kodu systemu,
- Context Mappingu,
- wykorzystania map kontekstów do ustalania zależności pomiędzy zespołami,
- zmianach zdarzeń na komendy.

Modelowanie domeny z użyciem Event Sourcingu wymaga wzięcia pod uwagę kilku czynników. Jednym z nich jest liczba zdarzeń, jaka będzie związana z modelowanym obiektem. Wraz z Oskarem Dudyczem, Developer Advocate w EventStore, rozmawiamy w tym odcinku o temporal modelingu, czyli modelowaniu obiektów w odniesieniu do upływającego czasu, kontroli długości strumieni zdarzeń i powiązanych problemach. Wszystko oczywiście w kontekście Event Sourcingu.

Do tej pory w rozmowach przewijał się temat EventStormingu, jako narzędzia do rozpoznawania domeny. Dzisiejszy gość, Michał Michaluk, pokazuje jak używa podejścia Behaviour-Driven Development, przy którego pomocy pozyskuje i systematyzuje wiedzę domenową.

W dzisiejszym odcinku będzie można posłuchać m.in. o:
- krótkiej historii BDD,
- stosowaniu tej techniki w praktyce,
- narzędziach wykorzystujących to podejście,
- praktycznych wskazówkach od Michała, aby taki warsztat był dla wszystkich uczestników wartościowy.

Tym razem odrywamy się na chwilę od kodu i zaczynamy patrzyć wyżej, na poziom całej organizacji. Często to tam kryją się problemy i wyzwania, które później dają o sobie znać zespołowi developerskiemu - wystarczy przypomnieć sobie choćby słynne prawo Melvina Conwaya o odwzorowywaniu w strukturze oprogramowania szlaków komunikacyjnych organizacji. Od 1967 roku dało o sobie znać w niejednym projekcie...

A jest ku temu specjalna okazja, bo gościem 31 odcinka Better Software Design jest Wojtek Ptak, obecnie Chief Technology Office w Talent Alpha, który posiada wieloletnie doświadczenie w pracy z zespołami IT, a w swojej karierze zawodowej pomógł przeprowadzić niejedną organizację przez proces transformacji. Przy jednej z takich zmian miałem przyjemność pracować z Wojtkiem i jego zespołem.

W tym odcinku będzie można posłuchać m.in. o:
- stosowaniu strategicznego Domain-Driven Design do nadawania kierunku rozwoju organizacji,
- prawie Conwaya i jego wpływie na wytwarzane oprogramowanie,
- narzędziach typu Lean Business Canvas, Business Model Canvas, Context Map i innych,
- nie zabraknie oczywiście wskazówek i porad Wojtka, a także odniesień do różnego rodzaju prezentacji i książek.

Przykłady przykładami, ale jeśli trafia się tylko okazja, to warto porozmawiać o prawdziwych projektach i ich wyzwaniach. Gościem 30-stego odcinka Better Software Design jest Wojtkiem Wiktorowicz, obecnie zajmujący stanowisko Head of Engineering, który na co dzień pracuje nad rozwojem i utrzymaniem platformy Displate - globalnego marketplace’u dla artystów. Skala projektu to 1.5 miliona unikalnych prac, 40 tysięcy artystów na platformie i 5 milionów plakatów rozsianych na całym świecie i sporo ruchu w aplikacji. Za to wszystko odpowiada 40-osobowy zespół Engineeringu i to właśnie o tym zespole, jego transformacjach, zmianach podejścia do tworzenia oprogramowania będziemy rozmawiać.