DDD w backendzie - kiedy ma sens i jak go wdrożyć?

W praktyce ddd architecture sprawdza się tam, gdzie logika biznesowa przestaje być prostym CRUD-em i zaczyna wymagać jasnych reguł, granic oraz wspólnego języka. W tym tekście pokazuję, jak rozpoznać, czy takie podejście ma sens, jak układać bounded contexts, jak zorganizować warstwy w Pythonie i co zmienia to w DevOpsie. To nie jest teoria dla teorii, tylko zestaw decyzji, które pomagają utrzymać backend w ryzach, kiedy system rośnie.

Czym jest DDD i kiedy ma sens w backendzie

DDD to podejście, w którym projektowanie zaczynam od domeny biznesowej, a dopiero potem dobieram strukturę kodu, bazę danych i sposób integracji. Innymi słowy: najpierw modeluję to, jak działa biznes, a dopiero później zastanawiam się, czy to będzie jeden moduł, kilka usług, kolejka zdarzeń czy klasyczny monolit. W praktyce to właśnie język domeny i model zachowania decydują o jakości całej architektury.

Ja zwykle sprawdzam bardzo proste kryterium: jeśli w systemie reguły są przewidywalne, zmienia się głównie zapis danych i większość ekranów wygląda podobnie, DDD może być zbyt ciężkie. Jeśli jednak pojawiają się wyjątki, stany przejściowe, wiele definicji tego samego pojęcia i sporo zależności między procesami, architektura DDD zaczyna naprawdę pomagać.

W praktyce dobrze zaprojektowany model domeny daje coś więcej niż estetyczny kod: skraca dyskusje z biznesem, upraszcza testowanie i zmniejsza liczbę miejsc, w których trzeba pamiętać o ukrytych regułach. To prowadzi wprost do najważniejszego elementu całego podejścia, czyli granic modelu.

Jak rozpoznać granice modelu i nie zrobić z systemu jednego worka

Granice w DDD wyznaczam nie po tabelach, tylko po znaczeniach. Jeśli to samo słowo w dwóch częściach systemu oznacza coś innego, mam bardzo mocny sygnał, że powinny to być dwa osobne bounded contexts, czyli obszary, w których model i język są spójne wewnętrznie, ale nie muszą być identyczne wszędzie indziej.

To szczególnie ważne w systemach backendowych, gdzie jeden termin potrafi żyć trzema życiami. W e-commerce „zamówienie” w sprzedaży, „zamówienie” w magazynie i „zamówienie” w rozliczeniach to często trzy różne modele. Jeśli zepchnę je do jednego wspólnego obiektu, prędzej czy później zacznę walczyć z nazwami pól, dodatkowymi ifami i przypadkowymi skutkami ubocznymi.

Przeczytaj również: AWS Fargate - Czy to naprawdę serwerless bez obowiązków?

Core, supporting i generic

W praktyce dzielę domenę na trzy grupy, bo to pomaga ustalić, gdzie naprawdę warto inwestować czas:

• Core domain to obszar, który daje produktowi przewagę. Tam opłaca się najwięcej modelowania i najwięcej dyscypliny.
• Supporting domain wspiera core, ale nie jest jego sercem. Tu nadal warto mieć porządek, ale nie trzeba budować najbardziej wyrafinowanego modelu.
• Generic domain to rzeczy typowe, jak autoryzacja, podstawowe powiadomienia czy proste integracje. Tę część zwykle opłaca się uprościć albo oprzeć na gotowych rozwiązaniach.

Takie rozróżnienie oszczędza czas. Nie próbuję modelować wszystkiego równie głęboko, tylko koncentruję się tam, gdzie błędna logika biznesowa kosztuje najwięcej. To samo podejście dobrze działa przy projektowaniu context map, czyli mapy relacji między kontekstami: pokazuje, kto od kogo zależy, gdzie trzeba tłumaczyć pojęcia i gdzie lepiej postawić barierę w postaci kontraktu lub warstwy pośredniej.

Gdy dwa konteksty muszą się dogadać, nie wpycham jednego modelu do drugiego. Zamiast tego wolę API, zdarzenia domenowe albo anti-corruption layer, czyli warstwę tłumaczącą pojęcia między modelami. To właśnie ten element najczęściej chroni system przed rozlaniem chaosu z jednej części na drugą.

Jak zbudować warstwy aplikacji w praktyce

Jeśli projektuję backend zgodnie z DDD, pilnuję wyraźnego podziału odpowiedzialności. Najprościej myśleć o tym tak: warstwa interfejsu przyjmuje żądanie, warstwa aplikacji koordynuje przypadek użycia, domena podejmuje decyzje biznesowe, a infrastruktura obsługuje bazę, broker wiadomości, cache i zewnętrzne API. W Pythonie to zwykle oznacza, że framework webowy i ORM są na zewnątrz, a model domeny pozostaje możliwie czysty.

W takim układzie entity ma tożsamość i własny cykl życia, value object opisuje wartość bez własnej tożsamości, a aggregate pilnuje spójności jednej grupy obiektów. Z kolei domain service przydaje się wtedy, gdy reguła biznesowa nie pasuje naturalnie do jednej encji, a repository ukrywa sposób zapisu i odczytu danych, zamiast stawać się kolejną warstwą SQL rozlaną po kodzie.

Największy test jakości jest prosty: jeśli po usunięciu frameworka aplikacja nadal da się przeczytać jak opis procesu biznesowego, jestem blisko dobrego modelu. Jeśli nie, prawdopodobnie model jest anemiczny, a logika siedzi w serwisach tylko dlatego, że tak wygodniej było na początku.

Jak połączyć DDD z mikroserwisami i DevOps

DDD i mikroserwisy często pojawiają się w jednym zdaniu, ale to nie to samo. DDD daje sposób myślenia o granicach i modelu, a mikroserwisy są jedną z możliwych implementacji tych granic. Ja zwykle ostrzegam przed zbyt szybkim skokiem do wielu usług, bo wtedy zyskuje się rozproszenie odpowiedzialności, ale traci prostotę operacyjną.

W praktyce dobrze dobrana granica techniczna powinna wynikać z granicy biznesowej, a nie odwrotnie. Jeśli jedna zmiana wymaga jednoczesnej aktualizacji kilku „niezależnych” serwisów, to znak, że granice zostały narysowane pod deployment, a nie pod domenę.

Tu szczególnie przydają się contract tests, czyli testy sprawdzające, czy jedna usługa nadal rozumie format i znaczenie danych drugiej. Dzięki nim nie muszę odkrywać w produkcji, że ktoś zmienił nazwę pola albo zaczął interpretować status w inny sposób. To samo podejście dobrze wspiera też rollback, bo zmiana staje się lokalna i przewidywalna, a nie rozlana po całym systemie.

Jeśli korzystam z mikroserwisów, staram się, by jeden serwis nie był mniejszy niż spójny fragment biznesu i nie większy niż jeden bounded context. To nie jest sztywna reguła, ale bardzo dobry punkt startowy. W praktyce najwięcej szkód robią serwisy zbudowane wyłącznie wokół tabel albo technicznych funkcji, bo potem trudno powiedzieć, kto naprawdę odpowiada za daną regułę.

Najczęstsze błędy, które psują taki projekt

Widziałem kilka powtarzających się błędów, które potrafią zabić wartość DDD jeszcze zanim zespół zdąży zobaczyć pierwszy efekt. Najgorsze jest to, że większość z nich wygląda początkowo bardzo rozsądnie.

• Anemiczny model domenowy - obiekty są tylko pojemnikami na dane, a cała logika siedzi w serwisach. To najkrótsza droga do proceduralnego kodu w ładnym opakowaniu.
• Granice narysowane po tabelach - jeśli moduły powstają tylko dlatego, że w bazie są osobne schematy, model biznesowy zwykle przegrywa z techniką.
• Za szybkie mikroserwisy - rozdzielanie systemu na wiele usług bez rozpoznania domeny kończy się drogą synchronizacją i dużym kosztem operacyjnym.
• Wspólna baza dla wszystkiego - to wygodne na starcie, ale później utrudnia autonomię i sprawia, że każdy kontekst może przypadkiem naruszyć cudze zasady.
• Przeprojektowanie prostych obszarów - nie każdy fragment systemu zasługuje na bogaty model, a próba zastosowania DDD wszędzie prowadzi do zbędnej komplikacji.
• Brak języka domeny - jeśli zespół i biznes nie używają tych samych pojęć, kod szybko zaczyna być poprawny technicznie, ale fałszywy biznesowo.

Najlepszy test, jaki znam, jest zaskakująco prosty: czy można opisać system w języku biznesu bez tłumaczenia każdego zdania na techniczne skróty? Jeśli nie, to problem zwykle nie leży w frameworku, tylko w modelu. I właśnie dlatego tak często wracam do pracy nad językiem, zanim ruszę z kodem.

Jak wdrożyć DDD bez przepalania budżetu

Jeśli miałbym wdrażać DDD w nowym albo już istniejącym backendzie, zrobiłbym to etapami. Chodzi o to, by najpierw zdobyć porządek w domenie, a dopiero potem inwestować w cięższe decyzje architektoniczne.

1. Wybieram jeden proces biznesowy - najlepiej taki, który sprawia najwięcej problemów albo przynosi najwięcej wartości. Nie modeluję wszystkiego naraz.
2. Spisuję język i reguły - razem z osobą z biznesu zapisuję pojęcia, stany, wyjątki i decyzje. To daje bazę do modelu domeny.
3. Buduję cienką warstwę aplikacji i bogatą domenę - use case’y zostają w warstwie aplikacji, a zasady biznesowe trafiają do obiektów domenowych.
4. Rozdzielam granice dopiero po zyskaniu jasności - jeśli system rośnie, wyciągam bounded contexts, kontrakty i osobne integracje, zamiast od razu rozbijać wszystko na mikroserwisy.

W projektach Pythonowych bardzo dobrze sprawdza się modularny monolit. Daje większość korzyści DDD przy znacznie mniejszym koszcie operacyjnym niż kilka osobnych usług, kolejki, osobne pipeline’y i rozproszone debugowanie. Jeżeli produkt nie wymaga jeszcze pełnej niezależności wdrożeń, to często jest to najbardziej rozsądny wybór.

W praktyce patrzę też na dwie rzeczy: czy zespół rzeczywiście rozumie domenę, oraz czy ma czas utrzymać dyscyplinę granic. Bez tego DDD łatwo zamienia się w estetyczną fasadę. Z tymi warunkami potrafi jednak dać dokładnie to, czego oczekuje backend: porządek, czytelność i mniejsze ryzyko, że kolejna zmiana rozsadzi cały system.

Co naprawdę zostaje z DDD w codziennej pracy nad backendem

Najbardziej praktyczny wniosek jest taki, że DDD nie polega na kolekcjonowaniu nazw wzorców, tylko na konsekwentnym pilnowaniu granic odpowiedzialności. To podejście pomaga pisać kod, który mówi językiem biznesu, szybciej ujawnia błędy w modelu i nie wymaga od zespołu pamiętania o każdym wyjątku w trzech różnych miejscach.

• Jeśli domena jest złożona, inwestuj w model i język.
• Jeśli granice są niejasne, rozdzielaj je po znaczeniu, nie po tabelach.
• Jeśli logika zaczyna puchnąć w serwisach, sprawdź, czy domena nie jest anemiczna.

W backendzie zbudowanym w Pythonie największy zwrot daje mi zwykle jedno: oddzielenie języka biznesu od frameworka i pilnowanie tej granicy w kodzie, testach oraz wdrożeniach. Gdy to działa, architektura przestaje być modnym hasłem, a staje się narzędziem, które realnie ułatwia rozwój produktu.