100. O AI w strategicznym Domain-Driven Design z Kubą Pilimonem
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.
Pamiętam, w jakim szoku byłem, że komuś tak naprawdę, wiesz, się chciało w te wszystkie rzeczy, o których my tam dyskutowaliśmy, tak głęboko wchodzić i to jeszcze potem gdzieś właśnie na Githuba w postaci jakichś notatek wrzucać. Dzisiaj te notatki, wiesz, przygotowalibyśmy AI-em. Chciałem powiedzieć, że to komuś się chciało bez LLM-a, to w ogóle mega szacun, tak. Tak, więc tym bardziej szacunek. A właśnie, jak jesteśmy wiesz co, przy takim temacie. No bo przez te kilka lat udało nam się wspólnie zrobić parę rzeczy. I warsztatów takich otwartych i gdzieś tam zamkniętych, no i Legacy Fighter, który też gdzieś tam takim bardzo fajnym efektem się gdzieś tam odbił w community. Natomiast wiesz, tak sobie teraz myślę, pamiętasz ile czasu i wysiłku my włożyliśmy w przygotowanie tego kodu? Tego takiego, wiesz, zrypanego, na którym chcieliśmy tak naprawdę pokazywać. Jakie tam moglibyśmy pomysły, jak ten kod przygotować, no bo tam się zastanawialiśmy, czy nie zlecić go do tworzenia tego kodu w różnych, wiesz, okolicznościach przyrody.
I warstwy operacyjne byłyby te specyficzne, bo to nie jest łatwe, sam wiesz, to nie jest łatwe i czasem jest to w jakiś sposób odwracające myślenie i kąt intuicyjny. Więc badając te drivery zobaczylibyśmy, która z tych opcji jest lepsza, być może opcja hybrydowa byłaby najlepsza. Jakbym podszedł do tego dzisiaj, Wydaje mi się, że w wielu aspektach podobnie, tylko ta ścieżka mogłaby być przyspieszona pewnymi technikami np. zbierania informacji za pomocą LLM-ów itd., synteza, research. Nie mówiąc już o samej fazie implementacji, bo o tym to pytanie nie jest, tylko bardziej o, że tak powiem, o szeroko pojęty design albo o, że tak powiem, jeszcze wcześniej analizę. Więc wsparłbym się pewnego rodzaju narzędziami bez wchodzenia w szczegóły, bo pewnie do nich przejdziemy później jakimi i jak.
Jakby zagadnienia związane z security, no troszeczkę znowu tutaj wrócą, wiesz, na świecznik. Ale dobra, to jakby odkopmy to pytanie, wiesz, odnośnie wykorzystania AI w Domain-Driven Design. Jak ty dzisiaj wykorzystujesz tego rodzaju narzędzia w swojej takiej codziennej pracy? Dobra, to jeżeli podzielimy sobie tak standardowo fazy DDD na początku, może nie fazy, tylko narzędzia skategoryzowane są na strategiczne, prawda, i na taktyczne. Zacznijmy od strategicznych, bo tam moim zdaniem jest więcej dużo cienia z użyciem tego typu narzędzi jak LLM. Moja obserwacja jest taka, Oczywiście mogę używać tego narzędzia i ja to robię np.
To jest dla mnie ciągle, ja to nazywam researchem mimo wszystko. Mimo, że wiem, że to jest jakby w naszej branży nazywane analizą. Natomiast w miejscach, o których mówiliśmy do tej pory w tym naszym odcinku, czyli ja muszę coś uogólnić, na przykład wracając do pytania twojego słuchacza, bo masz kilka krajów i tam są różne procesy, chcesz się jakoś uogólnić jakimś sprytniejszym modelem, To jest dużo trudniejsze niż suma przypadków. To jest dla mnie analiza i w tych miejscach dla mnie narzędzie pod tytułem LLM sprawdza się średnio. Tak po prostu, jak go użyję na pałę, podziel mi to na moduły, mam takie kraje, będą kolejne kraje, sprawdza się średnio. Jeżeli mogę się wtrącić, bo ja mam bardzo podobne doświadczenia. Jakiś czas temu na przykładzie właśnie naszego Legacy Fightera, gdzie na początku mieliśmy, wiesz, system, który był wybełtany, wiesz, mech, patyki i kamienie, a na końcu mieliśmy system zmodularyzowany.
I zrobiłem proste ćwiczenie. Dobra, przeanalizuj mi tą domenę. Tutaj masz opisane dodatkowe use case'y, które tam są. Właściwie, wiesz, chwilę czasu poświęciłem. Taksówki to były, nie? Tak, to był kaps, nie? Zaproponuj mi teraz podział, który umożliwi mi rozwijanie tego systemu w tym kierunku. Bo byłem bardzo ciekawy, czy efekt końcowy takiego właśnie zrzucenia na LLM-a tego zagadnienia modularyzacji będzie bardzo podobny albo chociaż zbliżony do tego, do jakich wniosków doszliśmy na końcu. I co było? Nie było. Nie było, właśnie. Nie, to taki klasyczny odrzeczownikowy niemalże podział. W kilku oczywiście sytuacjach to się tam zgodziło, z jakimś modułem taryf i tak dalej, natomiast nie było to aż tak pociągnięte, do jakich wniosków my doszliśmy. Być może oczywiście to była kwestia, wiesz, odpowiedniego preparowania prompta i tak dalej, i tak dalej.
Zresztą to ćwiczenie to wykonywałem jakiś czas temu. Natomiast pokazuje mi to, że albo będziemy musiały wykonywać dodatkowej pracy, żeby tych informacji wszystkich dostarczyć na temat, nie wiem, jakichś przyszłości, przyszłościowych use case'ów, użycia tego systemu i tak dalej, i tak dalej. żeby to narzędzie mogło ci tam podsunąć pewne rzeczy. Natomiast też nie ukrywam, że w kilku miejscach, gdzie stosowałem LLM-a do właśnie takiej, wiesz, propozycji modularyzacji, to podsuwało wnioski albo propozycje czy też, wiesz, pomysły, które faktycznie były warte pociągnięcia dalej, żeby okej, może w tym akurat jakimś aspekcie coś tam ciekawego jest. Czyli odpaliło ci pewne wątki w głowie, które sam sobie później przeprocesowałeś i sam własną intuicją, wiedzą, doświadczeniem potrafiłeś sobie odpowiedzieć na pytanie, czy ten wątek w ogóle dalej ma sens, czy nie.
Czyli, wiadomo, typowe, no tak, masz rację, przepraszam, nie wziąłem tego pod uwagę. Klasyka, nie? Oraz druga sytuacja jest taka, którą też w sobie widzę. Dlaczego mi się może wydawać, że to zadziałało mi? My jako ludzie mamy taką często tendencję, tak to wyrażę, do tego, żeby określać czy oceniać sensowność jakiejś techniki na podstawie stanu emocjonalnego, który czułem przy zastosowaniu tej techniki. Więc jak mi się dobrze gadało z tym LLM, bo nie jest człowiekiem, więc w końcu mogę gadać z kimś kompetentnym, tak mogę sobie pomyśleć. To jest super, będzie wynik, bo fajnie mi się gadało, więc wynik też na pewno musi być ekstra. Na to warto też zwrócić uwagę. Moja konkluzja w tym aspekcie tego strategicznego podziału jest taka, że robi to średnio.
Oczywiście mogę sobie wspomóc researchem, dokumentacją, to wszystko jest jasne, transkrypcją spotkań, szybszym zbieraniem informacji ze stormingu później, z Miro, takie rzeczy techniczne. Cudo, mega, fajne, ale i tak decyzje później ja podejmuję. Mogę robić je szybciej, te decyzje, na podstawie tych wszystkich technik, o których przed chwilą powiedzieliśmy i zbierania informacji i takich technikali, ale ciągle jednak po mojej stronie decyzja i lubię tak myśleć, bo lubię czuć się potrzebny, więc ja będę na razie przy tym stanowisku stał. Być może za rok je zmienię. A z jakich narzędzi korzystasz? Właśnie do robienia tego researchu? Ja najczęściej korzystam z Cloda. Korzystam sobie też z czata często. I z ewentualnie jakichś narzędzi, które są bramkami na LLM. To w zależności od tego, co tam klient na przykład ma, jeżeli ma.
Mogą być komendy, agentów, skille. Ja na przykład bardzo lubię mieć takich agentów, którzy pomagają mi jakąś taką standardową technikę, którą bym zrobił w głowie, ustrukturyzować i na przykład przeprowadzić tę technikę z kimś, kto, mówiąc bezczelnie, tej techniki w głowie nie ma albo nie chce mieć z jakiegoś powodu. Czyli przykładowo klasyfikacja reguł biznesowych, które tam z transkrypcji wynikają, że są. I mogę sobie zadać pytanie, Kurczę, czy to jest reguła walidacyjna, czy to jest reguła jakaś, wiesz, spójnościowa? To jest to, co mówiłeś, że ten pan powiedział, że jak stracimy tysiaka, to nic się nie stanie. Czyli tego typu pytania mogę jakoś wbudować w LLM, nie? W mojego agenta. To nie jest trudne. Mogę zadać pytanie na przykład, jeżeli biorę dane do decyzji, to czy one się mogą w trakcie podejmowania tych decyzji zmienić? No to jest takie standardowe pytanie. Jak tak, to czy to jest problem, czy nie? To mogę wbudować i na przykład powiedzieć, że jeżeli pytania, odpowiedzi na te pytania są negatywne...
A nie na przykład, że tam pojawi mi się słowo pricing per unit, czy na odwrót, jeżeli mapa kontekstów akurat tak wygląda. Do tego się nadaje świetnie i mam takiego agenta, który akurat klasyfikuje mi takie sytuacje. Bo najczęściej, wiesz, jak robisz code review, no to to są problemy, takie architektoniczne, że ktoś ci tam... Nawet nie tyle ENT je wciąga, bo to mogę też z testem zobaczyć jednostkowym, na archiunitach i tak dalej, albo między mikroservice'ami zobaczyć, że jest strzał, tylko że jakieś słownictwo przecieka, więc zaczynam w sposób niejawny kopiować logikę, która nie należy tutaj. I fuję na przykład na stringach. I ALM to wyłapie, a test nie. I to jest świetna zabawa, którą akurat w kłodzie mogę zrobić, a w innych narzędziach nie próbowałem. Tutaj dostrzegam, że kolejnym etapem, gdzie faktycznie nasza branża zostanie boosta, to jest to, że tego rodzaju rzeczy, o których teraz powiedziałeś, nie będą tylko i wyłącznie działały w interakcji developer-model, tylko będą tak naprawdę wprzęgnięte w cały system SDLC.
Nie mówiąc już wiadomo o takich wzorcach typu value object, czy fabryka, czy repozytorium, na ile sposobów możesz to robić. Jest 3, 4, 5 sposobów, które są po prostu skończone. Nie ma innych, więc Zrobienie tego za pomocą narzędzia jest idealne, jeżeli wykroisz wcześniej odpowiedni kawałek do tego, żeby to value object było. Akurat value object, propozycja LLM-ów to jest dobra, bo to są proste wzorce. Zazwyczaj trafia, bo to się nauczyło na dobrych wzorcach. Money i jakieś inne takie pierdoły. Pozwól, że nie będę cię pytał, wiesz, o jakby taki optymalny twój flow stosowania tych dwóch narzędzi, bo myślę, że ostatnie, wiesz, kilkanaście minut jakby pokazuje dokładnie, jak sobie to wyobrażasz. Natomiast masz jakieś takie własne tips and tricks, do których, wiesz, doszedłeś, jakieś best practices albo antypaterny, które wiesz, że cię albo, wiesz, boostują, albo powodują, że coś ci się tam dosyć mocno komplikuje?
Jakiś algorytm, niech to będzie wyszukiwania ścieżek, jest clue tego modelu, tak sobie oparłeś to, tak sobie to wymyśliłeś. I to działa. No to jeżeli mam tego typu architekturę i zakarmię tym rozwiązaniem jakieś moje narzędzie typu LLM, To ono mi bardzo szybko podpowie, jakie są inne algorytmy w ogóle w świecie grafów. I rozumie mapowanie mojego biznesu do tego algorytmu. Więc teraz oddolnie znając inne algorytmy, może mi przetłumaczyć, dobra, co mógłbyś jeszcze zrobić. Na przykład mógłby powiedzieć, wiesz co, szybciej, lepiej, optymalniej będzie, jak zastosujesz w ogóle inny algorytm do tego. Lub wygeneruje Ci inne pomysły biznesowe. Powie na przykład, wiesz co, jak weźmiesz różnicę z 4, 5, 6 grafów, 6 user journey, to zobaczysz na przykład, jakie są typowe różnice między klientem typu VIP, a klientem typu nie VIP.
Pokazano wszystkie 12 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.
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.