Domain-Driven Design pomaga wtedy, gdy w projekcie technika przestaje być głównym problemem, a zaczyna nim być sam biznes: jego reguły, wyjątki i słownictwo. W tym artykule wyjaśniam, czym jest to podejście, jakie pojęcia trzeba znać od początku, jak rozpoznać moment, w którym naprawdę się przydaje, i jak wdrożyć je bez niepotrzebnej komplikacji. Dodałem też praktyczny kontekst dla Pythona, bo właśnie tam dobrze widać różnicę między kodem, który tylko działa, a modelem, który rzeczywiście opisuje domenę.
Najważniejsze informacje o DDD w kilku punktach
- DDD porządkuje logikę biznesową wokół modelu domeny, a nie wokół tabel i endpointów.
- Najważniejsze pojęcia to: encja, obiekt wartości, agregat, repozytorium, serwis domenowy i bounded context.
- Wspólny język z biznesem jest ważniejszy niż sama liczba klas w projekcie.
- DDD ma sens przede wszystkim tam, gdzie reguły są złożone, często się zmieniają i łatwo o nieporozumienia.
- W prostych CRUD-ach pełne DDD bywa kosztowniejsze niż pożyteczne.
- W Pythonie najlepiej działa podejście warstwowe: domena osobno, infrastruktura osobno, ORM na granicy.
Czym jest DDD i kiedy rzeczywiście pomaga
Domain-Driven Design to podejście do tworzenia oprogramowania, w którym centrum uwagi stanowi model domeny, czyli uporządkowany opis reguł, pojęć i relacji występujących w biznesie. To nie jest framework, nie jest też gotowa architektura do skopiowania z jednego projektu do drugiego. DDD mówi raczej: najpierw zrozum problem biznesowy, a dopiero potem zamieniaj go na kod.
Ja traktuję to podejście jako narzędzie do pracy z złożonością. Jeśli system obsługuje płatności, logistykę, ubezpieczenia, rozliczenia, rezerwacje albo subskrypcje, liczba reguł szybko rośnie. Wtedy zwykły podział na kontrolery, serwisy i modele danych zaczyna być za mało precyzyjny, bo kod przestaje odzwierciedlać sposób myślenia biznesu.
| Sygnał w projekcie | Co to zwykle oznacza | Jak na to reaguję |
|---|---|---|
| Reguły biznesowe zmieniają się często | Logika domenowa jest ważniejsza niż sama warstwa techniczna | Modeluję przypadki użycia i pilnuję, żeby reguły nie rozlewały się po całym kodzie |
| Te same słowa znaczą coś innego w różnych działach | Brakuje wspólnego języka | Rozdzielam konteksty i doprecyzowuję słownik |
| Zespół rośnie, a kod staje się trudniejszy do zrozumienia | Potrzebne są wyraźne granice odpowiedzialności | Wprowadzam bounded contexty i porządkuję model |
| Projekt to prosty CRUD z kilkoma formularzami | Pełne DDD może być przesadą | Stawiam na prostotę i nie dokładam abstrakcji na siłę |
Jeśli widzę pierwszy, drugi i trzeci sygnał naraz, wiem, że problem nie leży w bibliotece ani w bazie danych, tylko w modelu. Wtedy najpierw porządkuję język i granice odpowiedzialności, a dopiero później sięgam po klasy i wzorce. Dzięki temu DDD działa jako sposób myślenia, a nie jako zbiór ozdobników architektonicznych.
Najważniejsze pojęcia, które trzeba znać
Bez kilku podstawowych terminów DDD bardzo szybko zamienia się w żargon. W praktyce najczęściej pracuję z sześcioma pojęciami, które tworzą szkielet całego podejścia. Jeśli zrozumiesz je dobrze, łatwiej będzie Ci ocenić, czy w danym miejscu warto modelować domenę głębiej, czy lepiej zostawić rozwiązanie proste.
| Pojęcie | Co oznacza | Na co uważać |
|---|---|---|
| Encja | Obiekt z własną tożsamością i cyklem życia, np. zamówienie lub użytkownik | Nie mylić encji z rekordem w bazie danych |
| Obiekt wartości | Element definiowany przez swoje cechy, np. pieniądz, adres albo zakres dat | Najczęściej powinien być niezmienny i prosty do porównania |
| Agregat | Zestaw obiektów, który ma jedną granicę spójności | Nie robić z niego wielkiej „kulki wszystkiego” |
| Repozytorium | Abstrakcja dostępu do agregatów, udająca kolekcję | Nie wkładać do niego logiki biznesowej |
| Serwis domenowy | Logika biznesowa, której nie da się sensownie przypisać do jednej encji | Nie używać go jako worka na wszystkie operacje |
| Serwis aplikacyjny | Warstwa, która koordynuje przypadek użycia i łączy elementy domeny | Powinien być cienki i nie zawierać reguł biznesowych |
Najbardziej zdradliwy błąd polega na pomyleniu serwisu aplikacyjnego z domenowym. Wtedy cała logika trafia do jednego pliku lub jednej warstwy, a model staje się anemiczny, czyli pozbawiony zachowania. Kod jeszcze wygląda „obiektowo”, ale w środku działa jak proceduralny skrypt z ładniejszymi nazwami.
Warto też pamiętać o pojęciu inwariantu, czyli reguły, która musi być zawsze spełniona. Dobrze zaprojektowany agregat chroni właśnie inwarianty, na przykład: zamówienie nie może zostać opłacone dwa razy albo rezerwacja nie może przekroczyć dostępnej puli miejsc. To jest moment, w którym DDD staje się naprawdę praktyczne, bo pomaga chronić biznes przed błędami, a nie tylko porządkować foldery w projekcie.
Jak działa wspólny język i granice kontekstów
Ubiquitous Language, czyli wspólny język, to jedno z najważniejszych założeń DDD. Chodzi o to, żeby zespół techniczny i osoby z biznesu używały tych samych pojęć w rozmowie, dokumentacji, testach i kodzie. Nie chodzi o idealną teorię, tylko o to, by słowa naprawdę oznaczały to samo dla wszystkich stron projektu.
W praktyce najwięcej błędów rodzi się tam, gdzie jedno słowo ma kilka znaczeń. „Klient” może oznaczać osobę kupującą w sklepie, firmę rozliczaną przez dział finansowy albo użytkownika zgłaszającego problem do supportu. „Zamówienie” też nie musi znaczyć tego samego w sprzedaży, magazynie i księgowości. DDD proponuje, by te różnice nazwać i zamknąć w osobnych bounded context, czyli wyraźnie wyznaczonych granicach, w obrębie których model ma jedno konkretne znaczenie.
To jest jeden z powodów, dla których DDD tak dobrze działa w większych organizacjach. Gdy model jest wspólny dla całego systemu, szybko pojawiają się sprzeczności. Gdy podzielisz go na konteksty, każdy fragment może być spójny sam ze sobą, nawet jeśli używa częściowo tych samych nazw. Dobrze zrobiona mapa kontekstów nie jest ozdobą architektury, tylko narzędziem do uniknięcia nieporozumień między zespołami.
Ja zwykle zaczynam od prostego pytania: gdzie ta sama nazwa zaczyna znaczyć coś innego? Jeśli odpowiedź pojawia się szybciej niż po kilku minutach rozmowy, to znak, że granica kontekstu już istnieje, tylko jeszcze nie została nazwana. Właśnie od tego momentu można przejść do implementacji, zamiast budować model „na całe przedsiębiorstwo” i później go rozrywać na siłę.
Jak wdrożyć DDD krok po kroku w małym lub średnim projekcie
Nie zaczynam od agregatów. Zaczynam od rozmowy o problemie. Wdrożenie DDD ma sens tylko wtedy, gdy jest stopniowe i oparte na realnych miejscach bólu, a nie na chęci przepisania całej aplikacji zgodnie z modą architektoniczną.
- Spisz pojęcia, których używa biznes, i sprawdź, czy wszyscy rozumieją je tak samo.
- Odszukaj obszary, w których reguły są skomplikowane, często się zmieniają albo powodują najwięcej błędów.
- Podziel system na bounded contexty i nazwij ich odpowiedzialność możliwie precyzyjnie.
- Modeluj tylko to, co naprawdę ma znaczenie dla domeny: encje, obiekty wartości i agregaty.
- Na końcu dodaj repozytoria i serwisy aplikacyjne, żeby połączyć domenę z bazą danych, API lub zadaniem w tle.
Najlepszy efekt daje podejście iteracyjne. Jedna dobrze zamodelowana ścieżka biznesowa jest więcej warta niż dziesięć abstrakcji, których nikt w zespole nie potrafi wytłumaczyć bez zaglądania do dokumentacji. Jeśli pracujesz na istniejącym systemie, nie próbuj przerabiać wszystkiego naraz. Wybierz jeden fragment, w którym logika jest najbardziej kosztowna, i tam pokaż wartość DDD.
Przy takim podejściu łatwiej też utrzymać testy. Reguły domenowe można sprawdzać bez całej infrastruktury, bo ich sens tkwi w modelu, a nie w frameworku webowym. To bardzo praktyczna zaleta, szczególnie wtedy, gdy projekt rozwija się długo i przechodzi przez ręce kilku zespołów.
Najczęstsze błędy, które psują efekt
DDD ma opinię podejścia mocnego, ale tylko wtedy, gdy używa się go świadomie. W przeciwnym razie łatwo zamienić je w rozbudowaną architekturę bez korzyści. Z mojego doświadczenia najczęściej psują efekt cztery konkretne błędy.
| Błąd | Dlaczego szkodzi | Co zrobić zamiast |
|---|---|---|
| Zaczynanie od abstrakcji zamiast od problemu | Model staje się teoretyczny i trudno go obronić przed zmianami biznesu | Najpierw opisz realne przypadki użycia i język domeny |
| Robienie z każdego obiektu encji lub agregatu | Model puchnie i traci czytelność | Stosuj tylko te pojęcia, które rozwiązują konkretny problem |
| Przeniesienie całej logiki do warstwy serwisów | Powstaje anemiczny model, który wygląda obiektowo, ale nie niesie zachowania | Umieszczaj reguły tam, gdzie naturalnie należą, czyli w domenie |
| Traktowanie DDD jak synonimu mikroserwisów | Można rozbić system za wcześnie i tylko zwiększyć koszty integracji | Najpierw uporządkuj model, a dopiero potem myśl o podziale technicznym |
| Pomijanie ekspertów domenowych | Programiści zaczynają zgadywać zamiast modelować rzeczywisty proces | Regularnie weryfikuj język i reguły z ludźmi, którzy znają biznes |
Najdroższy błąd to dla mnie mylenie DDD z dokręcaniem kolejnych warstw. DDD ma ułatwiać podejmowanie decyzji i zmniejszać liczbę nieporozumień, a nie robić wrażenie „poważnej architektury”. Jeśli po wdrożeniu trudniej wyjaśnić, gdzie jest logika biznesowa, to znaczy, że poszliśmy w złą stronę.
Co z tego wynika w projektach Pythona
Python bardzo dobrze nadaje się do DDD, bo jest czytelny, elastyczny i nie narzuca jednej ścieżki architektonicznej. To jednak miecz obosieczny: łatwo w nim stworzyć wygodny, ale rozmyty kod, w którym wszystko jest klasą, a nic nie ma wyraźnej odpowiedzialności. Dlatego w projektach Pythonowych szczególnie pilnuję granicy między domeną a infrastrukturą.
W praktyce najczęściej działa taki zestaw decyzji:
- dataclasses albo podobne lekkie struktury dobrze sprawdzają się przy obiektach wartości, takich jak pieniądz, adres czy zakres dat.
- typing.Protocol pomaga opisać kontrakty repozytoriów bez uzależniania domeny od konkretnego ORM-u.
- Modele ORM warto traktować jako część infrastruktury, a nie jako automatyczny rdzeń domeny.
- Pydantic świetnie nadaje się na granice API, ale nie każda walidacja wejścia musi stawać się modelem domenowym.
- W projektach webowych dobrze rozdzielić schematy żądań i odpowiedzi od właściwych obiektów biznesowych.
W Pythonie szczególnie łatwo pomylić wygodę z dobrym modelem. Dlatego ja zwykle mierzę sukces nie liczbą klas, ale tym, czy zespół potrafi opisać system tym samym językiem, którym posługuje się biznes. Jeśli regułę da się zmienić w jednym miejscu, testy są czytelne, a pojęcia nie mieszają się między modułami, to znaczy, że DDD zaczęło działać. I właśnie taki efekt jest w praktyce najcenniejszy.
