Sierpień 2025. Tydzień po założeniu fundamentów. Właśnie skończyłem moduł logowania — rejestracja działa, weryfikacja emaila działa, bezpieczeństwo wdrożone. Siedzę wieczorem 12 sierpnia i planuję kolejne konteksty aplikacji.
Pułapka nadmiernego planowania
Mam przed sobą Excel z listą kontekstów:
- Logowanie (zrobione ✅)
- Uprawnienia (system ról)
- Weryfikacja adresów
- Zarządzanie profilem
- Ustawienia prywatności
- Ocena zaufania
- Komunikacja
- Powiadomienia…
- Analityka i raporty
21 oddzielnych kontekstów kodu. Dla aplikacji która ma 0 użytkowników.
Chwila — co ja właściwie robię?
Czytałem Erica Evansa (Domain-Driven Design) i Vaughna Vernona (Implementing DDD). Podejście DDDDDD (Domain-Driven Design)Projektowanie kodu wokół biznesu, nie technologii — kod odzwierciedla to, co aplikacja robi dla użytkownika. czytaj więcej → mówi: każda spójna część biznesu = osobny kontekstKontekst (bounded context)Spójna część systemu z własną granicą, modelem i językiem. Zmiana wewnątrz nie rozlewa się na resztę. czytaj więcej → (bounded context). Ma sens dla banku z 50 programistami i milionami klientów. Ale juz-ide to na razie jeden programista i trzy miesiące do pierwszej wersji.
Test „zmieniają się razem”
Vernon ma regułę prostą: jeśli dwie rzeczy zmieniają się razem, trzymaj je razem. Jeśli każda żyje swoim życiem, rozdziel.
Spojrzałem na swoją listę przez ten pryzmat:
Logowanie + Uprawnienia — zmiana ról wymaga aktualizacji w obu miejscach. Dodanie logowania przez Google wymaga zmian zarówno w procesie logowania, jak i w przydzielaniu uprawnień. Usunięcie konta? Porządki w obu modułach. Zmieniają się razem.
Komunikacja + Zaangażowanie — wysłana wiadomość może wywołać powiadomienie. Dodana reakcja aktualizuje wskaźniki aktywności. Zmieniają się razem.
Zlecenia + Oferty usług — oba to marketplace. Różnią się modelem biznesowym (aukcja vs ogłoszenie), ale system opinii, płatności, weryfikacja zaufania — wszystko współdzielone. Zmieniają się razem.
Większość moich 21 kontekstów nie żyła swoim życiem. Planowałem granice dla problemu którego nie mam.
Trzy opcje
Opcja pierwsza: Zostać przy 21 kontekstach. „Prawidłowe” DDD — każdy kontekst osobno, jasne granice, przygotowane na przyszłość. Brzmi dobrze w książce. W praktyce? Jeden programista przeskakujący między 21 modułami to koszmar organizacyjny. Plus 3 miesiące do MVP — niemożliwe.
Opcja druga: Monolit — wszystko w jednym miejscu. Najszybsze tempo pracy, brak granic, prosto. Byłem tu już kiedyś. Prototyp po 6 miesiącach zamienił się w spaghetti. Porządkowanie kosztowało 2 miesiące. Nie chcę powtarzać błędu.
Opcja trzecia: Start z 6 kontekstami — minimum potrzebne TERAZ. Dodaję więcej jak zajdzie potrzeba, na podstawie faktów, nie przypuszczeń.
Równowaga. Vernon pisze: zacznij od dużych kontekstów, dziel gdy pojawi się ból. Nie planuj dla 10 000 użytkowników kiedy masz 0.
Wybrałem trzecią opcję.
6 kontekstów które mają sens
Zmniejszyłem z 21 do 6:
Konto i uprawnienia — Logowanie, rejestracja, sesje, role, uprawnienia. Scalenie ma sens bo jedno bez drugiego nie działa.
Geografia — TERYT (polskie podziały administracyjne) + PostGIS (geografia w bazie danych). Weryfikacja adresów, zapytania geograficzne, zasięg sąsiedztwa.
Społeczność — Komunikacja i zaangażowanie razem. Wiadomości, powiadomienia, reakcje, komentarze. Interakcje między sąsiadami.
Gospodarka — Marketplace. Zlecenia krótkoterminowe i oferty usług razem. Opinie, oceny, zaufanie.
Wymiana — Wymiana rzeczy między sąsiadami i wydarzenia lokalne.
Platforma — Analityka, panel administracyjny, moderacja. Funkcje wspierające, nie główna wartość biznesowa.
Co scaliłem i dlaczego? Logowanie bez uprawnień to połowa systemu. Wiadomości bez śledzenia aktywności to brak wiedzy o zaangażowaniu. Zlecenia i oferty usług to ten sam marketplace, tylko inny model biznesowy.
Kompromis który akceptuję
Mniej „czyste” DDD. Niektóre konteksty robią „za dużo” — Konto obsługuje i logowanie, i role. Społeczność obsługuje i wiadomości, i powiadomienia.
Ale tempo znacznie szybsze. Zamiast zarządzać 21 modułami, zarządzam 6 które rozumiem.
Co jeśli będę musiał podzielić któryś kontekst? Przygotowałem się. Każdy scalony kontekst ma wewnętrzne podfoldery. Podział to przeniesienie folderu i aktualizacja połączeń. Tanio.
Gdzie jestem
Logowanie i rejestracja gotowe. Bezpieczeństwo wdrożone. 6 startowych kontekstów zaplanowanych i udokumentowanych.
Na ten moment nie wiem jeszcze: czy 6 kontekstów wystarczy przez cały MVP? Sprawdzę za miesiąc. Plan: przegląd co 2 tygodnie. Podział jak pojawi się ból. Na podstawie faktów, nie spekulacji.
Wniosek: Rozwiązuj problemy które MASZ, nie które MOŻESZ MIEĆ.
Starachowice, 17 sierpnia 2025
Jak to działa od środka (dla ciekawych)
Architektura PRZED i PO
Plan początkowy: 21 oddzielnych kontekstów — m.in.: logowanie, uprawnienia, profil użytkownika, ustawienia prywatności, weryfikacja geograficzna, ocena zaufania, komunikacja, powiadomienia, zaangażowanie, reakcje, zlecenia, oferty usług, wymiana rzeczy, wydarzenia, płatności, opinie, analityka, administracja, moderacja i inne.
Po konsolidacji: 6 startowych kontekstów
- Konto i uprawnienia — logowanie, rejestracja, sesje, role
- Geografia — weryfikacja adresów (TERYT), zapytania przestrzenne (PostGIS)
- Społeczność — wiadomości, powiadomienia, reakcje, komentarze
- Gospodarka — marketplace (zlecenia krótkoterminowe + oferty usług)
- Wymiana — wymiana rzeczy i wydarzenia lokalne
- Platforma — analityka, administracja, moderacja
Zasady konsolidacji
Kryterium scalenia: test „zmieniają się razem” — jeśli 2 rzeczy zmieniają się razem, trzymaj je razem (Logowanie + Uprawnienia → razem, bo jedno bez drugiego nie działa).
Kryterium podziału: „pojawia się ból” — jak kontekst robi zbyt wiele niepowiązanych rzeczy, rozdziel. Na podstawie faktów, nie przypuszczeń.
Przygotowanie do podziału: Każdy scalony kontekst ma wewnętrzne podfoldery. Podział = przeniesienie folderu i aktualizacja importów.