Nowe otwarcie - powrót po latach

 Nowy początek - przemyślenia

Ponad cztery lata po stworzeniu event stormingu na temat aplikacji "Maraton Rowerowy" (kawałek event stormingu plus kod) i sześć lat po zakończeniu ostatniej edycji (kod do ostatniej edycji), postanowiłem wrócić do tego tematu.

Zachęciła mnie do tego chęć przybliżenia sobie wzorca Domain Model. Być może powinienem go znać, gdyż ES z maratonu powstał na bazie szkolenia DNA gdzie wałkowane było DDD, ale wtedy nie zrozumiałem dobrze tego wzorca. Kod napisany po poprzednich częściach DNA był no cóż kiepski.

Po pięciu latach zrozumiałem że sercem DDD jest model i stąd ten pomysł żeby w końcu spróbować za modelować, porządnie, jakiś kontekst z maratonu. 

Każda firma w której pracowałem, miało jakieś legacy, projekty, które uczą jak nie programować, do których nie wchodzi się z uśmiechem na twarzy, a bardziej z trwogą. Czasami sam robiłem takie legacy i zostawiałem w odmętach danej firmy, tak było jak pracowałem na kopalni. 

Jeżeli chce innego wyniku to nie mogę nonstop rozwiązywać problemu w taki sam sposób. 

W obecnej firmie,  też mamy legacy system, ale zmieniło się coś we mnie zacząłem dostrzegać w nim potencjał, ma on swoje ciemne strony, ale ma też spore pole do refaktoringu, zrozumienia naszego biznesu. Legacy to nie tylko problem ale to część czyjeś historii, zestaw decyzji, które zaważyły na aktualnym stanie. Czas pokazuje, że nie wszystkie były trafne ale czy to powód do krytyki? nie sądzę.

Wróciłem do książki  Praca z zastanym kodem, sięgnąłem również po książkę Martina Fowlera, dotyczącą refaktozyzacji, mam też szkolenie Legacy Fighter i w tym ostatnim droga prowadzi z legacy do DDD.

Nie mogłem też w moim zestawieniu pominąć Andrzeja Krzywdy występującego w podcaście Better Software Desing mówiącym o refaktoryzacji. Te lektury, sprawiły że legacy zacząłem widzieć w innym świetle, legacy stało się wyzwaniem nie tylko problemem.

Świat związany z programowaniem zmienia się tak szybko, nie nadążam już, jestem człowiekiem po czterdziestce, czasami potrzebuje czegoś stabilnego, czegoś czemu mogę zaufać, czegoś niezmiennego.

Są takie rzeczy od lat stałe, choćby normalizacja baz danych, koncept z przed półwieku, taki stary to każdy go pewno zna i rozumie. Nic bardziej mylnego. DDD, przecież to ma z 20 lat, kogo się nie spytasz to zna DDD i jeszcze w tym pracuje, a jak zgłębisz temat to jest tak samo jak z normalizacją.

Może nie trzeba szukać nowych frameworków, może wystarczy zrozumieć te stare, wciąż aktualne koncepty? zrozumieć i używać, ale używać tam gdzie to jest potrzebne.

Ostatnia rzecz, która wydaje się niezmienna od lat, to potrzeby klienta, użytkownika, biznesu i zrozumienie tego, zrozumienie ich.

Krótka historia.

Pisałem aplikacje do obsługi maratonu rowerowego w latach 2013 - 2019. Co roku tworzyłem na nowo, uczyłem się na tym, nie było jeszcze AI, który by mi wygenerował kod, może coś by wymyślił, podpowiedział, poprawił. Jak kończyłem ostatnią edycje pojawił się temat event stormingu, zachwyciło mnie te podejście, to była końcówka roku 2018, jeździłem wtedy jeszcze na meetup-y, zobaczyłem ES i spodobało mi się. Odkryłem narzędzie którego mi brakowało, sposób na zrozumienie, dogadanie się z drugą stroną.

Dlatego poszedłem na DNA?, bo był event storming, reszta mnie nie interesowała, w między czasie przeczytałem DDD Erica Evansa (strasznie nudna książka). 

Rok temu zacząłem, na nowo odkrywać DDD, wracać do ES, wydaje mi się że musiało minąć 5 lat żeby coś zrozumieć, coś wykiełkowało, doszło do mnie. Do książki Erica Evansa też wróciłem, już nie jest nudna.

Ale ta droga nie była taka jak sobie ją na początku wymarzyłem, po kilku próbach z kolegami, po których pozostały :

• ES - sklep,
• ES - maraton

Przyszedł czas na test w boju, dostałem zadanie napisania aplikacji do zarządzania przedsiębiorstwem produkującym, wynajmującym i sprzedającym automaty do gier. Żeby zrozumieć proces i kontekst, zaproponowałem event storming. Spotykaliśmy się przez dwa miesiące, bo to był projekt który robiłem po pracy, zaczęło się i skończyło na ES-ie. Po analizie trzeba było zrobić wycenę, poszło o kasę, ale robiąc event storming już wiedziałem że nie dam rady tego "wyklepać", miałem za małe doświadczenie, umiejętności.

Teraz jak bym dostał takie zadanie, nie próbował bym go zrobić, raczej spróbował bym co się da oddelegować na gotowe narzędzia i zaproponować integracje, a kodzić jak najmniej. Mądry ten kto napisał że "najlepszy kod to taki który nie istnieje".

Te doświadczenia spowodowały  u mnie odejście od event stormingu, skupienie się nad poprawą warsztatu. Nie da się jednak uciec od problemów, od legacy. Można narzekać na taki kod ale to on często przynosi największą wartość firmie. To on ma największy potencjał do zmiany, niełatwej ale możliwej, to tu można się najwięcej nauczyć.

Dlaczego powrót do Event Stormingu? Dzięki nie mu mogę lepiej zrozumieć proces, odkryć reguły, znaleźć granicę, ale jest coś ważniejszego. Ta druga strona, biznes, może współtworzyć  to, może być częścią tego procesu wyklejania karteczek i może go rozumieć. Tekst wszystkiego nie ogarnie, nie w taki sposób jak tablica na Miro, gdzie będę mógł widzieć cały proces i powiększyć sobie kawałek z niego, przejść przez "Happy patha" ale też wyznaczyć ścieżki mniej oczywiste. Nie będzie potopu słów którego nie jestem w stanie szybko ogarnąć bez robienia sobie dodatkowych notatek.

Zdobywanie wiedzy od biznesu i tak polega na rozmowie tylko zamiast "excela", dostaje borda z karteczkami.

Plan

Post ten powstał żeby na nowo zrozumieć DDD, wzorzec domain model i sam event storming ale w tej kolejności. Głównym zadaniem będzie nauczyć się modelować i w tym pomocny będzie temat "Maratonu rowerowego", oraz event stormingu który został dla nie go stworzony. To ułatwi mi następujące etapy:

• rozpisać jeden lub dwa konteksty odkryte na event stormingu z maratonu rowerowego,
• rozpisać scenariusze w obrębie wybranego kontekstu, coś takiego jest w rozdziale o budowaniu agregatów w książce Erica Evansa o DDD,
• na koniec chce spróbować to zamodelować w kodzie 

To co robiłem do tej pory opierało się o modele anemiczne nawet jak logika byłą większa, potrzebowałem kolejnego roku żeby to zrozumieć, żeby nie bać się modelu, to tam ma być logika nie gdzie indziej.

Pozostała też kwestia, że w mojej pracy starałem się promować model anemiczny, co było błędem z mojej strony, ktoś by mógł zadać pytanie przecież zrobiłeś kurs DNA, czytałeś Evansa, słuchałeś podcastów, czytałeś artykuły, to gdzie to wszystko się podziało?

Dobre pytanie, może tak naprawę nigdy nie rozumiałem? Może potrzebowałem czasu żeby dostrzec te rozwiązaniem bo nie zawsze DDD jest słuszne czasami model anemiczny pasuje, relacje w bazie są właściwe a czasami, potrzebuje tabel bez relacji albo bazy nierelacyjnej.

Wydaje mi się że w moim przypadku to czas, problemy, kod, coraz częstsze pytania i wątpliwości z powrotem doprowadziły mnie do tego miejsca.