Mentionsy

No i przed AI-owych.

No i w sumie to też właśnie, dlaczego tego wspominam, wiesz co, bo chciałbym, żebyśmy teraz troszeczkę tak zajrzeli właśnie, co się pozmieniało jakby też w naszym postrzeganiu Domain-Driven Design, naszym postrzeganiu architektury i naszej codziennej pracy.

Dzisiaj te notatki, wiesz, przygotowalibyśmy AI-em.

Przygotowaliśmy i staraliśmy się tak naprawdę pokazać przejścia refaktoryzacyjne, takie jakie my stosujemy, w kontekście też wykorzystania Domain-Driven Design.

Czyli takie wszystkie jakieś antypaterny, które gdzieś tam mieliśmy okazję zobaczyć, postaraliśmy się tak naprawdę zaimplementować, a potem z tego wyjść.

Czy istnieją narzędzia w Domain-Driven Design Toolboxie do radzenia sobie z silnie konfigurowalnymi produktami?

Przede wszystkim, czy być może jest tam miejsce na archetyp produktu, na archetyp łączania tych produktów, na archetyp tego, jakie produkty mogą się lub nie mogą łączyć, czyli constrainty, czyli powiedzmy wariacja w ogóle wszystkich

Na razie o AI to żeśmy jeszcze nie podyskutowali.

I teraz archetypowe rzeczy na przykład już bym zdelegował do AI, ponieważ mam taki kod już napisany i byłoby mi łatwiej zająć się tymi specyficznymi.

I tak podsumowując, samo Domain-Driven Design takiego toolboxa mi de facto nie daje.

Ale słuchaj, właśnie, bo jak tutaj wspominasz, wiesz, Domain-Driven Design, tutaj rozmawiamy o kontekście czasu.

Jestem szczerze mówiąc bardzo mocno zainteresowany, jak zmieniało się w ogóle twoje postrzeganie Domain-Driven Design na przestrzeni, wiesz, ostatnich lat.

To sobie takie moje zainteresowanie i chęć używania tego tak bardzo mocno ewoluowała.

Już pamiętam jakieś tam gdzieś faktycznie jakieś tam spotkania, w których się odkrywało, że okej, dobra, to my czasami jako zespół IT, zespół deweloperski bardzo chcemy tej spójności chronić i faktycznie jesteśmy w stanie, wiesz, pokazać to, zaimplementować i super, nie naruszysz tego, wiesz, no matter what.

Tak samo wiesz, jak się zmieniało zainteresowanie taką subdomeną, bounded-kontekstem itd.

Jak rozmawiamy właśnie sobie o kontekście czasu, no to wiesz, od naszej ostatniej rozmowy wydarzyła się i się w sumie cały czas dzieje, cały czas ta AI-owa rewolucja.

Jak mocno ty wykorzystujesz właśnie AI w swojej pracy i jak to wszystko łączysz z Domain-Driven Design?

Bo ja mam takie podejście w naszej branży od wielu lat, na przykład sobie blockchain przeczekałem, stwierdziłem, że przeczekam.

Dzięki temu byłem powiedzmy w tym czasie szczęśliwszym człowiekiem, nie musiałem się, nie musiałem szukać roboty, w której robiłem blockchaina, bo to teraz mi się do niczego nie przydało.

Idąc dalej blockchainem był taki moment NFT, pamiętasz?

Byłem takim użytkownikiem, który, wiesz, no... No, sobie sformatowałem maila z moich literówek, bo ja po prostu dużo literówek tworzę.

To powiedziałaś o cieniach, to może zaczniemy od cieni, a potem odpowiem na twoje pytanie, które ciągle pamiętam od DDD i AI, bo tak haczyliśmy o te cienie.

No i tutaj się zastanawiam, w stosunku właśnie też do Domain-Driven Design, w jaki sposób jesteśmy w stanie tutaj zbudować to wspólne zrozumienie, jeżeli w bardzo wielu przypadkach każdy sobie rzepkę skrobię.

Mogę zaproponować jakieś funkcje, mogę nawet ładnie, w cudzysłowie, później się do tego pewnie odniesiemy w kontekście DDD, ładnie podzielić moduły, ale nie zaprojektuje mi AI system pod konkretną strategię, konkretne tempo zmian, czy np.

W dobie AI mogę mieć iluzję, podkreślam iluzję, redukcję tego procesu, iluzję, do kilku promptów i jeszcze mogę zapewnić się innym promptem, że moje rozwiązanie jest dobre, bo jak sam wiesz, to narzędzie świetnie podbija moje pomysły, jeżeli chce, żeby podbiło i wytłumaczyło komuś, czemu ten pomysł jest super, bo mogę tak go użyć,

Żeby AI domknęło moją narrację, zamiast ją kwestionować.

Bo taki architekt, jeżeli nie widzi sprzeczności, to AI nie wyciągnie tych sprzeczności na wierzch, a nawet jak wyciągnie, to on je zignoruje.

Natomiast jeżeli się przytrafi błąd, a umówmy się, on się przytrafił wcześniej czy później, to jest tylko kwestia czasu, słynny paraben MTBF, Mean Time Between Failure, i to walnie na produkcji, to teraz z jaką szybkością będę w stanie się przez to przebić, zrozumieć, co faktycznie się stało i w jaki sposób mam poprawić specyfikację.

Jeżeli mówimy o jakimś małym module, dobra, to mogę wejść i nawet czasami oczywiście sam AI może mi jeden czy drugi pomóc wskazać ten mój oczywisty błąd.

A w niektórych jeszcze masz Shadow AI, nie?

Ale dobra, to jakby odkopmy to pytanie, wiesz, odnośnie wykorzystania AI w Domain-Driven Design.

AI pięknie podzieliło system na moduły.

Ktoś pisze o tym, że AI zastąpi wszystkich wszędzie i zawsze jest jakiś obrońca, moralizator, który mówi, patrzcie, nie, ten człowiek mówi bullshity i ja go sprawdzam teraz.

I tłumaczenie, które tam zostało pokazane, że to nie był błąd sztucznej inteligencji, tylko błąd człowieka, ponieważ człowiek dał AI-owi zbyt duże uprawnienia.

Ja kiedyś słyszałem, jeszcze nie w kontekście naszej branży, ale takie naiwne głosy, że no przecież kurczę, jeżeli damy sztukę inteligencji władze i każemy jej naprawić raka, wyleczyć raka, to stwierdzić najlepiej ludzi, bo przecież wtedy rak zniknie, w sensie z ludzi zniknie.