Przez ten blog przewija się sporo pojęć z Domain-Driven Design i z naszej domeny: kontekst, agregat, zdarzenie domenowe, Result, PostGIS, TERYT. Zamiast tłumaczyć je w kółko w każdym wpisie, zebrałem je tutaj — po ludzku, bez akademickiego żargonu.
To strona referencyjna. Wracaj tu, gdy w którymś wpisie coś zabrzmi obco. Pojęcia oznaczone w tekście kropkowanym podkreśleniem pokazują krótką definicję po najechaniu — a „czytaj więcej” prowadzi właśnie tutaj.
Podstawy DDD
DDD (Domain-Driven Design)
Projektowanie kodu wokół biznesu, nie technologii. Zamiast organizować kod warstwami („tu baza, tu kontrolery, tu logika”), organizujesz go wokół tego, co system robi dla użytkownika. Nazwy w kodzie = nazwy z biznesu (to się nazywa ubiquitous language — wspólny język). Dzięki temu, czytając kod, widzisz domenę, nie instalację techniczną.
Kontekst (bounded context)
Wydzielony fragment systemu z jasną granicą. Wewnątrz panuje jeden spójny model i język; na zewnątrz komunikuje się przez zdefiniowane wejścia i wyjścia. Dzięki temu „Konto” może rozumieć słowo użytkownik inaczej niż „Gospodarka”, bez konfliktu. Zmiana wewnątrz kontekstu nie rozlewa się na resztę systemu.
To kluczowe pojęcie tego bloga — gdy piszę „kontekst”, mam na myśli właśnie to, nie zwykły „obszar kodu”.
Agregat (aggregate)
Grupa powiązanych obiektów, którą zapisujesz i zmieniasz jako całość. Ma „korzeń” (aggregate root) — jedyny punkt wejścia. Pilnuje niezmienników, czyli reguł, które zawsze muszą być prawdziwe (np. „zlecenie nie może mieć ujemnej kwoty”). Jedna transakcja obejmuje jeden agregat.
Obiekt wartości (value object)
Obiekt definiowany przez wartość, nie tożsamość. Dwa adresy o tych samych polach są równe — nie mają osobnego „ID”. Jest niezmienny (zmiana = nowy obiekt) i może mieć wbudowaną walidację oraz ochronę — np. PESEL jako obiekt, który sam maskuje się w logach.
Zdarzenie domenowe (domain event)
Fakt, który już zaszedł w domenie, opisany w czasie przeszłym: UserRegistered, JobCompleted. Inne konteksty nasłuchują i reagują bez sztywnego sprzęgania — po rejestracji ktoś wysyła powiadomienie, ktoś inny nalicza punkty zaufania, a żaden z nich nie musi wiedzieć o istnieniu drugiego.
Wzorce, które stosuję
Wzorzec Result
Zamiast rzucać wyjątek w środku logiki biznesowej, funkcja zwraca Result — opakowanie mówiące „udało się + dane” albo „nie udało się + powód”. Wyjątki zostają dla awarii infrastruktury (padła baza), a przewidywalne błędy biznesowe („email zajęty”) są zwykłą wartością do obsłużenia. Logika domeny zostaje czysta.
CQRS
Command Query Responsibility Segregation — rozdzielenie zapisu (komendy) od odczytu (zapytania). Zapis może być bezpieczny i transakcyjny, odczyt — szybki i prosty. Nie muszą używać tego samego modelu danych.
ACL / rejestr kontekstów
Anti-Corruption Layer — warstwa-tłumacz między kontekstami. Jeden kontekst nie sięga do wnętrza drugiego; rozmawiają przez tłumacza. Dzięki temu zmiana w jednym nie psuje drugiego, a granice pozostają czyste.
Process manager
Koordynator długiego procesu biznesowego rozłożonego na wiele kontekstów (np. weryfikacja → aktywacja → powiadomienie). Reaguje na zdarzenia i wydaje komendy, trzymając własny stan kroku. Alternatywa dla sagi-orkiestratora.
Z naszej domeny
PostGIS
Rozszerzenie PostgreSQL o dane geograficzne: punkty, wielokąty, zapytania „w promieniu X km”. W juz-ide służy do sprawdzania, czy ktoś naprawdę jest z danego sąsiedztwa.
TERYT
Oficjalny krajowy rejestr jednostek terytorialnych i adresów. juz-ide używa go, by zweryfikować, że podany adres istnieje i należy do danej miejscowości — to fundament „zweryfikowanego sąsiada”.
Brakuje pojęcia, które gdzieś mignęło? Daj znać — słownik rośnie razem z blogiem.