Pisałem już o własnej bibliotece do DDD — i o tym, że na pewnym etapie świadomie odłożyłem jej rozwój. Zostało jednak pytanie, które pewnie chodzi za każdym, kto to czytał: skąd w ogóle u mnie ta potrzeba budowania wszystkiego według DDD?
Odpowiedź nie jest techniczna. Jest osobista — i muszę cofnąć się dużo dalej niż sam juz-ide.
Najpierw było „po swojemu”
Nie skończyłem informatyki. Wszystkiego, co umiem, nauczyłem się sam — zaczynając od frontendu, z którego z czasem przeszedłem na backend. Wiedzę składałem z trzech źródeł: trochę własnych prób, trochę lektury, a najwięcej z kursów na Udemy, na które przepaliłem dosłownie tysiące godzin.
Projektów w pierwszych latach było mnóstwo — hobbystycznych i komercyjnych. Działały raz lepiej, raz gorzej. I to jest sedno: wiele decyzji, które podejmowałem na starcie „bo tak było szybciej”, odbijało mi się czkawką później. Zmiana, która powinna zająć godzinę, zajmowała dzień, bo wszystko było ze sobą posklejane.
Znałem wzorce — ale tylko te taktyczne: jak napisać klasę, jak rozbić funkcję, jak poukładać katalogi. Brakowało mi tego piętro wyżej: jak w ogóle myśleć o całości, żeby nie zamieniła się w plątaninę.
Zderzenie ze ścianą
To się zmieniło, gdy dołączyłem do projektu zbudowanego inaczej: DDD, architektura warstwowa (onion, clean architecture) i CQRS. Miałem już wtedy na koncie mikroserwisy i aplikacje rozproszone w chmurze — myślałem, że jestem przygotowany.
Nie byłem. Przez pierwsze tygodnie nie mogłem się odnaleźć. To było jak przesiadka z angielskiego na chiński — niby dalej programowanie, ale każdy plik, każda warstwa rządziły się logiką, której nie rozumiałem.
Obsesja popołudniami
Robiłem jedyną rzecz, jaką umiałem: drążyłem. Całe popołudnia i wieczory szły na to, żeby zrozumieć, o co w tym wszystkim chodzi. Budowałem własny, mały projekt — linia po linii, plik po pliku. Dosłownie drukowałem sobie logi, żeby zobaczyć, co się wywołuje, w jakiej kolejności i gdzie. Na początku to była totalna magia.
Potem firma dostała kolejny projekt i wrzucono mnie na głęboką wodę jeszcze raz. I wtedy ten wzorzec, który rozgryzałem obsesyjnie po godzinach, zakotwiczył się we mnie na dobre. Czytałem dalej, uczyłem się DDD wieczorami przez kolejne miesiące i lata. Nawet gdy nie pracowałem już w takim projekcie — każdy mój własny projekt był rozwinięciem tych samych zasad.
W pewnym momencie to przeskoczyło. DDD stało się jak prowadzenie auta: wsiadasz do nieznanego modelu, ale od razu wiesz, gdzie jest kierownica, pedały, regulacja fotela. W każdym aucie trochę inaczej — ale po chwili po prostu jedziesz.
Czemu nie wracam do „po swojemu”
Dziś nie wyobrażam sobie budowania aplikacji inaczej. Tak, kodu jest wyraźnie więcej. Ale koszt utrzymania i łatwość rozbudowy z nawiązką to rekompensują — a w czasach, gdy sporą część kodu pisze się z AI, jeszcze bardziej. Jasne granice i przewidywalna struktura to coś, z czym model współpracuje znacznie lepiej niż z plątaniną „po swojemu”.
To nie jest stanowisko „DDD do wszystkiego”. To wniosek z moich własnych potknięć: te decyzje na starcie, które odbijały się czkawką, brały się głównie z braku struktury. DDD dało mi tę strukturę.
Stąd pomysł na własną bibliotekę
W TypeScripcie jest kilka bibliotek do DDD. Próbowałem ich — i żadna nie trafiała w to, czego chciałem: elastyczności, a jednocześnie trzymania konceptów i granic w ryzach. Albo za sztywne, albo zostawiające zbyt wiele przypadkowi.
Tak narodził się pomysł, żeby napisać własną — taką, która powstaje i dojrzewa razem z prawdziwym projektem: moim startupem i komercyjną aplikacją juz-ide.pl. Nie w próżni, tylko na realnych potrzebach.
Jedna ważna zasada: nie wymyślam koła na nowo. Biblioteka czerpie z dojrzałych rozwiązań sprawdzonych produkcyjnie w innych językach — Javie, C# i innych — często rozwijanych po 10–20 lat przez inżynierów znacznie lepszych ode mnie. Nie chciałem tworzyć czegoś bez pokrycia w prawdziwym świecie IT. Moja rola jest skromniejsza: użyć LLM, żeby przenieść te sprawdzone idee do TypeScriptu i móc budować na nich własne projekty.
Czy to się obroni? Czas pokaże. Ale to jest właśnie ten wątek, który opisuję tu na żywo — łącznie z tym, co pójdzie nie tak.
Jeśli czytałeś wcześniej, jak odłożyłem rozwój tej biblioteki albo jak ciąłem liczbę kontekstów w juz-ide — teraz wiesz, skąd to wszystko się bierze. To nie był kaprys ani moda. To suma tych wszystkich popołudni nad cudzym kodem.