Better Software Design

CQRS, czyli Command Query Responsibility Segregation, jest wzorcem wyjątkowo popularnym i powszechnie stosowanym w wielu systemach. Mało kto jednak sięgnął po oryginalny dokument autorstwa Grega Younga, który opisuje założenia tego konceptu architektonicznego i z czasem obrósł on kilkoma mitami.Dziś w podkaście ponownie gości Oskar Dudycz, z którym na tapet weźmiemy zarówno mity jak i fakty dotyczące wzorca CQRS. A gdy przy drugim mikrofonie pojawia się Oskar, to wiadomo, że będzie do bólu pragmatycznie...W tym odcinku rozmawiamy m.in. na temat:czym jest wzorzec CQRS i jaki ma związek z językiem Eiffel i ideą CQS Bertranda Meyera,związku z wzorcem Command & Command Handler,xszeregu mitów, którymi CQRS obrósł na przestrzeni lat, np. koniecznością stosowania asynchroniczności,różnych możliwych sposobach, w jaki CQRS może zostać zaimplementowany w systemie.Materiały dodatkowe:CQRS, oryginalny dokument Grega Younga, opisujący koncept CQRSCQRS Bliki, artykuł na bliki Martina Fowlera o omawianym wzorcuCQRS facts and myths explained, artykuł na blogu Oskara na poruszony w rozmowie tematOd CRUD do CQRS w praktyce, prezentacja Oskara z konferencji bITconf 2022Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:https://twitter.com/mariuszgilhttps://instagram.com/mariuszgil_dev/https://youtube.com/c/MariuszGil

Mylić się to rzecz ludzka, propagować automatycznie te błędy to DevOps... Tym razem na tapet bierzemy historie o tym, jak to produkcja płonęła i jakie wnioski zostały z tego wyciągnięte.Dziś moimi gośćmi w podkaście są Jarek Pałka i Wojtek Ptak, a w takim gronie nie wypada zamiatać spraw pod dywan. A że warto uczyć się na błędach, a najlepiej tych popełnianych przez innych, wyciągniemy parę naszych błędów z przeszłości. Oprócz tragikomicznych aspektów niektórych z przytoczonych tu sytuacji, będzie to bardzo dobry wstęp do znacznie ważniejszych wątków.W tym odcinku rozmawiamy m.in. o:naszych błędach i wyciągniętych wnioskach,różnych źródłach problemów i ich typach, od błędów ludzkich po limity infrastrukturalne,mierzeniu rzeczy, by określić wpływ fuckupu na otaczający nas świat,przygotowywaniu się na incydenty, bo to nie kwestia czy wystąpią, tylko kiedy,jakie działania podejmować w trakcie problemu,kulturze postmortems, lessons-learned i upewnianiu się, że wnioski,jak i kiedy komunikować o problemach,co zrobić, gdy fala sztormu odpłynie w dal...Będę bardzo zobowiązany za wypełnienie krótkiej ankiety na temat tego odcinka.Materiały dodatkowe:Death March - Edward YourdonThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win - Gene Kim, Kevin Behr, George SpaffordNormal Accidents: Living with High-Risk Technologies - Charles PerrowThe Idealcast with Gene Kim by IT Revolution - rozmowa z dr. Ronem Westrumem m.in. na tematy związane z problemami w złożonych systemach (od 34:45)The Facebook Outage - postmortem problemu FacebookaRoot Cause Analysis: A Quick Guide - opracowanie na temat wspomnianego w odcinku RCASoftware Testing Lessons Learned From Knight Capital Fiasco - analiza przypadku Knight Capital i utraty ponad 400M USD

Często uciekamy od danych i analizujemy zachowania w procesach biznesowych, a równie często to właśnie dane są podstawą do budowy zaawansowanych systemów IT. Zanim dotkniemy gwarantujących spójność agregatów, nasze operacje przechodzą przez systemy oparte o sztuczną inteligencję czy uczenie maszynowe i to właśnie tym zagadnieniom dziś się przyjrzyjmy.Zapraszam dziś na odcinek z wielu powodów dla mnie szczególny, ponieważ moim gościem jest Piotr Gawrysiak, Chief Data Scientist w mBanku i profesor Politechniki Warszawskiej, osoba o ogromnej wiedzy w tematach AI/ML, a także Process Miningu. Po 30 latach życie napisało tu piękną klamrę, bo choć dziś będziemy wspólnie rozmawiać o projektowaniu rozwiązań data-driven czy automatycznej analizie procesów biznesowych, to dawniej chłonąłem treści tworzone przez Piotra pod szyldem magazynów Bajtek i Top Secret... Piotr uchyli rąbka tajemnicy i pokaże jak kierowany przez niego zespół wspiera mBank na polu analizy danych i projektów ML.W tym odcinku rozmawiamy m.in. o:projektach opartych w ML/AI w banku,rodzajach problemów możliwych do rozwiązania z użyciem Machine Learningu,procesie tworzenia rozwiązań data-driven,wykorzystywanych technologiach i potrzebnych umiejętnościach w kwestii data-science,późniejszym wdrażaniu przygotowanych modeli i podejścia do dzielenia się danymi,process miningu i automatycznej analizy procesów,wpływie modeli typu ChatGPT-3 na pracę developerów.Zapraszam na odcinek!Materiały dodatkoweIT w mBanku, więcej rozmów z ekspertami i tematy dookoła software-house'u ITKursy Andrew NG, kilka kursów od Andrew NG w specjalizacjach Machine Learning, MLOps i Deep LearningProcess Mining Warsaw, grupa meetupowa poświęcona tematyce optymalizacji procesów z użyciem Proces MininguBiblioteka pm4py, implementacja algorytmów Process Mining w PythonieOdcinek powstał we współpracy z mBankiem.

Wiele tematów potrafi podnieść temperaturę rozmowy, zaczynając choćby od osławionego pytania "taby czy spacje". Ale kiedy skręcamy w rejony związane z Agile i pada słowo SCRUM, konwersacja często przechodzi na zupełnie nowy poziom. Do rozmowy na temat realiów SCRUM-a i sposobu jego stosowania zaprosiłem Kubę Szczepanika i Jacka Wieczorka, których wiele osób zna np. ze świetnego podcastu Porządny Agile.W tym odcinku rozmawiamy m.in. na temat:SCRUM Guide i jego stosowania w praktyce,codziennych porannych teatrzykach,wybierania ze SCRUM-a tylko jego elementów, czyli o tzw. SCRUM-Butachzastępowania go znacznie lepszymi i bardziej dopasowanymi technikami,kulturze organizacji i SCRUM Masterach,przypadkach, gdzie te metoda ma sens i gdzie go zupełnie nie ma...Zapraszam!Materiały dodatkowe:PorządnyAgile.pl, podcast Kuby i Jacka na tematy związane z podejściami zwinnymiKiedy SCRUM nie jest odpowiedzią, #68 odcinek podcastu Porządny Agile rozwijający wątek o niedopasowaniu SCRUM-a do danej sytuacjiLabirynty SCRUM-a, książka autorstwa Jacka WieczorkaAgile247.pl, sporo właściwej wiedzy o Agile'u, można tu znaleźć wiele artykułów obu gościZapraszam Cię także do odwiedzenia moich innych miejsc w internecie:https://twitter.com/mariuszgilhttps://instagram.com/mariuszgil_dev/https://youtube.com/c/MariuszGil

Niezależność od frameworka, interfejsu użytkownika, bazy danych i innych systemów zewnętrznych, a także wsparcie testowalności - to podstawowe filary takich konceptów architektonicznych jak Clean / Hexagonal / Onion / Sreaming Architecture, DCI, BCE. Poszczególne podejścia różnią się w szczegółach, jednak w zbliżony sposób podchodzą do rozdzielania systemu na mniejsze, dedykowane warstwy. Z moim dzisiejszym gościem, Oskarem Dudyczem przyglądamy się dziś pierwszej pozycji tej listy i analizujemy mocne i słabe strony Clean Architecture, zaproponowanej przez Roberta C. Martina.W tym odcinku rozmawiamy m.in. o:czym jest Clean Architecture i skąd wywodzi się ta idea?stosowaniu zasad SOLID na poziomie architektury całego systemu,proponowanych w Clean Architecture zasadach i warstwach,zaletach i wadach tego rozwiązania,pewnych podobieństwach i różnicach w odniesieniu do np. Hexagonal Architecture,stosowaniu tego rodzaju architektury w kontekście projektu i zespołu.Zapraszam!Materiały dodatkowe:The Clean Architecture - wpis na blogu Roberta C. Martina (Uncle Boba), który można także znaleźć w jednym z rozdziałów książki Clean ArchitectureClean Architecture - książka autorstwa Roberta C. Martina, 2017, wydawnictwo PearsonPutting SOLID into Perspective - artykuł Jeremiego Millera o stosowaniu zasad SOLID w kontekście projektowania i rozwoju architekturyPowiązane z tematem artykuły na blogu Oskara:What onion has to do with Clean Code?Generic does not mean SimpleHow to slice the codebase effectively?

W trakcie implementacji systemu często stajemy przed problemem kontroli uprawnień i decydowaniu, czy pozwalamy użytkownikowi wykonać określoną operację. Ten jeden, pozornie prosty IF w kodzie jest pretekstem do dzisiejszej rozmowy z Bartkiem Słotą, na temat kontroli uprawnień w projekcie opartym o techniki Domain-Driven Design.Na konkretnym przykładzie przejdziemy proces analityczno-modelarski i rozważymy możliwe opcje, ich zalety i wady. Materiały dodatkowe:Fragment EventStormingu, a także mapa kontekstów z przedstawionymi relacjami znajdują się na boardzie Miro: https://miro.com/app/board/uXjVPq0-LUM=/W odcinku pojawiają się narzędzia i herystyki modelowania, o których szerzej posłuchać można we wcześniejszych odcinkach podcastu:BSD #43 O subdomenach biznesowych ze Sławkiem SobótkąBSD #37 O Context Mappingu z Bartkiem SłotąBSD #26 O perspektywach Being, Behaving, BecomingBSD #8 O Bounded Contextach ze Sławkiem Sobótka

O tym, że procesy biznesowe istnieją i że są ważne wiedzą wszyscy. Potrafimy o nich ogólnie mówić na poziomie abstrakcyjnym, ale też umiemy schodzić na niższe poziomy i opisywać ich działanie zdarzeniami lub BPMN-em. Natomiast o regułach często mówi się tylko na ogólnym poziomie, jeśli w ogóle, że "no jakieś tam reguły są w biznesie". Są traktowane trochę jak czarna magia, jak jakiś mityczny stwór. Trochę jak synonim "logiki biznesowej". Reguły biznesowe to jest bardzo konkretna rzecz, za którą stoi mocna teoria, własny standard (SBVR by OMG). która ma nie tylko praktyczne przełożenie na naszą pracę ale wręcz może zrewolucjonizować niektóre aspekty.Takie wprowadzenie do dzisiejszego tematu otrzymałem od mojego gościa, Aleksandra Bartnikiewicza, z którym rozmawiamy o regułach biznesowych, analizie domeny w oparciu o tę wiedzę, zapisie, semantyce i dokumentowaniu reguł. Nie będzie to odcinek poświęcony implementacji reguł w kodzie, ale uważny słuchacz znajdzie zapewne od razu odniesienia do Domain-Driven Design, chronionych agregatami niezmienników lub innych implementacjami zakazów i nakazów.W tym odcinku rozmawiamy z Aleksandrem m.in. o:- czym są, a także czym nie są reguły biznesowe i jak się mają do procesów w domenie,- odpowiednim wyrażaniu i semantyce reguł, aby poprawnie opisywały zasady działania biznesu,- podejściu Evansa vs podejście Rossa do języka biznesowego,- budowanie słowników i dokumentowaniu wiedzy na tem reguł biznesowych,- stosowaniu rulebooka w większym projekcie i zespole.Zapraszam! Na blogu Aleksandara znaleźć można artykuł Model pojęciowy - Diagram, który przedstawia wizualną stronę wspomnianego w odcinku przykładu.Materiały dodatkowe:Manifest Reguł Biznesowych, polska wersja manifestu Business Rules GroupThe Business Rules Manifesto*, angielska wersja 2.0 manifestu, listopad 2003Business Rule Concepts : Getting to the Point of Knowledge, wspomniana książka Ronalda RossaBusiness Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business, kolejna warta uwagi pozycja RossaDla wytrwałych odnośnik do specyfikacji SBVR, Semantics Of Business Vocabulary And Business Rules.

Materiały dodatkowe:Functional Event Sourcing Decider, źródłowy artykuł na blogu Jérémiego Chassaing na temat implementacji wzorca DeciderFunctional Event Sourcing, nagranie prezentacji Jérémiego z DDD Europę 2020, niestety bez obrazu z laptopaHow to effectively compose your business logic, artykuł Oskara na temat kompozycji logiki z wzorcem DeciderHow events can help in making the state-based approach efficient, eventowe podejście do zmiany stanu systemuWriting and testing business logic in F#, kolejny artykuł z bloga Oskara na temat użycia Decidera, tym razem w F#

Materiały dodatkowe:8-krokowy process przeprowadzenia zmiany, podsumowanie wspomnianego przez Krzysztofa frameworka Johna KotteraTechnology Strategy Patterns: Architecture as Strategy, książka Ebena HewittaNerd Management, video podcast Krzysztofa i Pawła na tematy związane z zarządzaniem zespołami IT

Materiały dodatkowe:CUPID - the back story, pierwszy artykuł Dana Northa o kwestionowaniu zasad SOLIDCUPID - for joyful coding, kontynuacja tematu na blogu Dana NorthaCUPID - for joyful coding, nagranie prezentacji z konferencji NDC London 2022Patterns of Software: Tales from the Software Community, Richard P. Gabriel