Domain-Driven Design w praktyce: Jak tworzyć kod, który oddycha biznesem

Domain-Driven Design – gdy deweloperzy i eksperci biznesowi mówią jednym językiem

Wyobraź sobie projekt, w którym programiści i osoby z biznesu naprawdę się rozumieją. Domain-Driven Design (DDD) to podejście do tworzenia oprogramowania, które właśnie to umożliwia – buduje most między światem technicznym a biznesowym.

W DDD programiści współpracują z ekspertami domenowymi, by stworzyć wspólny model domeny – spójne spojrzenie na problem, które można bezpośrednio przełożyć na kod. Zamiast zgadywać, co miał na myśli biznes, zespół techniczny pracuje ramię w ramię z osobami znającymi realia danej branży.

Kluczowym elementem jest ubiquitous language – wspólny język oparty na pojęciach z domeny. Jeśli mówimy „koszyk”, to oznacza to dokładnie to samo w rozmowie, dokumentacji i w kodzie. Dzięki temu unikamy nieporozumień i budujemy systemy, które rzeczywiście odzwierciedlają sposób działania firmy.

DDD to nie tylko technika – to sposób myślenia, który usprawnia komunikację, zwiększa zrozumienie problemów biznesowych i prowadzi do bardziej trafnych, elastycznych rozwiązań.
Od czego więc zacząć?

Od kliknięcia do dostawy – jak Domain-Driven Design pomaga zaprojektować system płatności w e-commerce?

Przyjrzyjmy się teraz, jak podejście Domain-Driven Design działa w praktyce – na przykładzie procesu płatności w sklepie internetowym. To klasyczny scenariusz, w którym dobra współpraca między zespołem technicznym a ekspertem domenowym ma kluczowe znaczenie.

Wyobraź sobie, że budujesz system e-commerce. Klient dodaje produkty do koszyka i klika „Zapłać”. W tym momencie uruchamia się cały łańcuch zdarzeń domenowych. System weryfikuje poprawność zamówienia, oblicza końcową kwotę, a następnie przekazuje ją do modułu Płatności, który inicjuje transakcję.

Po potwierdzeniu płatności w ruch idzie kolejna część systemu – moduł Magazynu. Otrzymuje sygnał do realizacji zamówienia, pracownicy kompletują paczkę, a klient dostaje potwierdzenie zakupu i przewidywany termin dostawy.

W tym artykule skupimy się wyłącznie na domenie sklepu – a dokładniej na tym, jak opisać odpowiedzialność poszczególnych komponentów systemu z perspektywy biznesowej. Zakładamy, że mamy już uzgodniony z ekspertem domenowym wspólny model procesu – np. w formie diagramu przepływu. To nasz kontrakt, który będzie podstawą dalszego projektowania.

Zamiast zagłębiać się od razu w detale techniczne, potraktujemy system jak firmę – z działami (czyli modułami), które współpracują ze sobą, by zrealizować zamówienie. A co najważniejsze: wszyscy – programiści i eksperci biznesowi – rozumieją ten model w ten sam sposób, bo opiera się na wspólnym języku domeny.

Czym właściwie jest serwis domenowy w Domain-Driven Design?

Serwis domenowy to element modelu domenowego, który odpowiada za realizację logiki biznesowej niezwiązanej bezpośrednio z żadną konkretną encją. Jego głównym zadaniem jest odzwierciedlanie rzeczywistych scenariuszy biznesowych w kodzie.

Gdy tworzę serwis domenowy, zawsze zaczynam od ustalonego kontraktu z ekspertem domenowym – np. diagramu przepływu lub opisu procesu. Używam dokładnie tego samego słownictwa, które pojawia się w rozmowach z biznesem. Dzięki temu każdy etap procesu ma swoje czytelne i spójne odwzorowanie w kodzie, a model pozostaje zgodny z językiem domeny (ubiquitous language).

Zwykle szkicuję cały proces na raz – definiując wszystkie potrzebne klasy i metody, ale bez wdrażania szczegółów technicznych. Dlaczego? Bo to logika biznesowa i język domenowy powinny kształtować strukturę kodu, a nie odwrotnie.

Dobry serwis domenowy – podobnie jak cały model domenowy – powinien być wolny od zależności technologicznych. Powinien działać niezależnie od frameworka, bazy danych czy infrastruktury technicznej. Implementacja algorytmu biznesowego nie powinna wymagać konfiguracji kontrolerów, repozytoriów czy warstw aplikacyjnych.

To podejście ma ogromną zaletę podczas prototypowania: możesz szybko testować i weryfikować swój model, łatwo go zmieniać, a efekty omawiać z ekspertem domenowym. Dzięki temu iteracyjnie rozwijasz system, który faktycznie oddaje reguły rządzące Twoją domeną.

Elementy DDD, które warto znać

W pracy z Domain-Driven Design nie chodzi o to, by za wszelką cenę „wdrożyć DDD”, tylko by mądrze skorzystać z jego narzędzi wtedy, gdy naprawdę pomagają. W moich projektach często pojawiają się pewne powtarzalne elementy — wzorce, które dobrze się sprawdzają w uporządkowaniu złożonej logiki biznesowej i ułatwiają rozmowę z ekspertami dziedzinowymi. 

Oto te, które najczęściej wykorzystuję:

1. Agregaty, fabryki agregatów i repozytoria - jak ShopingCart, warstwa nadająca obiektowości klasycznym encją.

2. Value Objects - niezmienne obiekty jak ClientID, Item czy Price, które tworzą wzbogacone struktury danych

3. Serwisy fasadowe - EventBus czy PaymentService, które ukrywają złożoność zewnętrznych systemów

4. Polityki - FeePolicy czy PromoPolicy, które enkapsulują reguły biznesowe

Przejdźmy teraz do omówienia każdego z nich. 

Agregat - Czym właściwie jest Agregat?

Agregat to obiekt, który możesz zidentyfikować, ma swój stan i możesz go zmieniać. Domyślne przyjęcie za agregat każdego obiektu, na którego stan wewnętrzny możemy wpływać bardzo ułatwia intuicyjne podejście do tego wzorca. Inaczej mówiąc jest to narzędzie do nakładania obiektowości na relacyjny model danych reprezentowany przez encje.

Weźmy na warsztat coś, co znasz z codziennego życia - koszyk zakupowy. Możesz go stworzyć, dodać do niego produkty i ostatecznie zapłacić. Twój koszyk zawiera produkty, może uwzględniać promocje i dodatkowe opłaty.

Czy zauważyłeś, że właśnie opisaliśmy złożony obiekt z jego zachowaniami? To właśnie istota agregatu! Nie pytasz koszyka "daj mi listę produktów, abym mógł ją zmienić" - zamiast tego mówisz "dodaj ten produkt" lub "usuń tamten".

Jak zbudowany jest Agregat?

Agregat składa się z encji (Entity), które są jego częściami składowymi. Te encje przechowują dane, które trzeba zapisać w bazie. Są jak szkielet agregatu - zapewniają strukturę, ale same w sobie nie mają zachowań biznesowych.

A dlaczego nie umieścić wszystkich danych bezpośrednio w agregacie (sprawić by agregat jednocześnie encją)? Takie rozdzielenie daje większą elastyczność. Możesz używać encji niezależnie, na przykład w zapytaniach do bazy danych. Dodatkowo, oddzielasz gettery i settery od logiki biznesowej.

Ważna zasada: agregat nie udostępnia swoich wewnętrznych encji. Komunikuje się ze światem przez Value Objects. To jak w sklepie. Nie pozwalasz innym grzebać w magazynie, tylko podajesz konkretną towar na półce.

Praktyczne zasady pracy z Agregatami

Jeśli pracujesz z obiektem, którego stan możesz zmieniać - masz do czynienia z agregatem. To klasyczny obiekt OOP, bez tradycyjnych getterów i setterów. Zamiast nich ma metody odzwierciedlające jego zachowanie biznesowe.

Nie zapisuj agregatu bezpośrednio w bazie danych. Zawsze używaj dedykowanego repozytorium. Agregaty to nie tylko struktury danych, ale przede wszystkim zachowania. Cześć z nich wymaga wcześniejszego zainicjowania.

Twórz agregaty przez dedykowane fabryki. Pomyśl o tym jak o produkcji samochodu - nie składasz go ręcznie z części, tylko zamawiasz w fabryce, która wie jak to zrobić poprawnie.

Agregat powinien zawierać logikę biznesową swojej domeny. Jeśli masz agregat `Pies`, metoda `jedz(kiełbasa)` powinna być jego częścią. Jest to naturalne i intuicyjne - pies zjada kiełbasę, a nie `pies.getŻołądek().setPokarm(kiełbasa)` jest nią aplikowany.

Korzyści z używania Agregatów

Stosowanie agregatów sprawia, że Twój kod staje się bardziej zrozumiały. Każdy agregat ma jasno określoną odpowiedzialność i granice. Łatwiej zapewnisz spójność danych i zachowań biznesowych.

Agregaty pomagają również w zarządzaniu złożonością. Duże systemy dzielisz na specjalizowane obiekty z jasno określonymi granicami. To jak organizacja firmy w departamenty - każdy ma swoją specjalizację i protokoły komunikacji.

Jak działa repozytorium agregatu?

Repozytorium agregatu działa jak pośrednik między Twoim modelem domeny a bazą danych. Przekłada surowe dane na użyteczne obiekty biznesowe.. I odwrotnie – zamienia Twoje obiekty z powrotem na dane.W najprostszych przypadkach repozytorium jedynie opakuje encję w obiekt agregatu, w bardziej złożonych może wstrzykiwać np serwis słownikowy i inne usługi.

Jedną z największych zalet repozytoriów jest ich elastyczność technologiczna. Możesz przygotować repozytorium dla dowolnej technologii przechowywania danych. Podczas prototypowania często uruchamiam model z funkcji "main" i używam zwykłego pliku jako repozytorium. Nie ma znaczenia, czy korzystasz z MongoDB, PostgreSQL czy plików tekstowych. Dopóki repozytorium poprawnie inicjuje agregat, możesz dowolnie zmieniać bazę danych lub serwis usług typu CRUD.

Wyobraź sobie repozytorium jako uniwersalny adapter – podłączasz je do dowolnego źródła danych, a Twój model działa bez zmian.

W moim podejściu stosuję wielokrotny zapis do repozytorium po każdej zmianie stanu obiektu. Na poziomie serwisu domenowego nie używam transakcji, co jest zgodne z zasadami architektury mikroserwisów. W takim środowisku transakcje mogą powodować problemy, szczególnie gdy komunikujesz się z innymi serwisami. Jednak nie wyklucza to zastosowania transakcji wewnątrz agregatu na poziomie repozytorium.

Czy nie lepiej, żeby Twój model biznesowy był niezależny od infrastruktury i frameworka? DDD to przede wszystkim sposób na zabezpieczenie wiedzy domenowej. Podstawowe funkcje języka programowania zwykle wystarczają do opisu modelu biznesowego. To jak budowanie z klocków Lego – proste elementy, ale możliwości nieograniczone.

Dzięki takiemu podejściu mogę szybko prototypować i weryfikować model biznesowy. Moje repozytorium nie musi opierać się na bazie danych – może być zaimplementowane jako plik lub zewnętrzne API. Cały proces mogę testować nawet z poziomu funkcji main. Jest to jak jazda próbna samochodu przed zakupem – sprawdzasz, czy model działa, zanim zainwestujesz w całą infrastrukturę.

Pamiętaj, że nie ma sztywnych zasad tego co powinno znajdować się w agregacie. Model powinien jak najlepiej oddawać charakter domeny ale też bez przesady. Jeśli coś staje się nazbyt skomplikowane warto to ponownie przeanalizować. Warto eksperymentować z różnymi podejściami i znaleźć to, które najlepiej pasuje do Twojego projektu.

Dlaczego warto stosować fabrykę agregatu?

Wyobraź sobie fabrykę agregatu jako specjalistyczne stanowisko montażowe. Składasz tam skomplikowany produkt, ale nie martwisz się o jego magazynowanie. To zupełnie inne zadanie. Podobnie w kodzie - warto oddzielić tworzenie obiektu od jego zapisu i odczytu.

Tworzenie obiektów często wymaga więcej logiki biznesowej niż ich zapis. Czy sprawdzasz poprawność danych przed utworzeniem konta użytkownika? To właśnie rola fabryki. Zajmuje się ona walidacją danych i pobieraniem informacji z zewnętrznych źródeł.

Zauważyłeś, jak prosta może być implementacja? Fabryka zajmuje się logiką tworzenia, podczas gdy repozytorium skupia się wyłącznie na przechowywaniu danych.

Value Objects - kiedy proste typy to za mało

Czy kiedykolwiek zastanawiałeś się, dlaczego warto owijać podstawowe typy w dedykowane klasy? Przyjrzyjmy się temu na praktycznych przykładach, które zmienią Twoje podejście do modelowania domeny.

Z klasą BigDecimal w Javie nie ma większych problemów. To solidne narzędzie (mimo kilku pułapek, które warto znać przed rozmową kwalifikacyjną). Dlaczego więc zawracać sobie głowę tworzeniem klasy Price?

Pierwszym powodem jest język domeny. Wyobraź sobie rozmowę z ekspertem biznesowym o Twoim kodzie. Klasa nazwana "Price" będzie dla niego znacznie bardziej zrozumiała niż techniczny "BigDecimal".

Value Object daje Ci możliwość tworzenia dedykowanych metod fabrykujących. Ja preferuję nazwę "of" dla takich metod - podobnie jak w bibliotece Google Guava. Dzięki nim zyskujesz idealne miejsce na walidację danych wejściowych.

W klasie Price możesz od razu zadbać o właściwą liczbę miejsc po przecinku. Możesz też dodać kod waluty i inne szczegóły biznesowe. Wszystko dzieje się w jednym, kontrolowanym miejscu.

W tym przypadku zamiast gotowego kodu posłużę się przykładem użycia.

Value Object - praktyczny przykład z numerem bankowym

Pomyśl o numerze konta bankowego. Możesz przechowywać go jako zwykły String. Ale co zyskasz tworząc Value Object nazwany IBANNumber?

Przede wszystkim kod staje się bardziej czytelny. Dodatkowo, możesz stworzyć różne warianty inicjalizacji:

- `IBANNumber.of(String countryCode, String number)`

- `IBANNumber.of(String ibanNo)`

Do takiej klasy możesz dodać metodę zwracającą informacje o banku. Możesz też załączyć funkcję formatującą numer do prezentacji. Brzmi lepiej niż zwykły String, prawda?

Zasady tworzenia dobrych Value Objects

Value Object powinien być zawsze niezmienny (immutable). Dodając Price do Price tworzysz trzeci, nowy obiekt - podobnie jak przy dodawaniu liczb.

Jest to pełnoprawny obiekt w paradygmacie OOP. Zawiera metody biznesowe związane z operacjami, które reprezentuje. To jak mały ekspert w swojej dziedzinie.

Statyczne metody fabrykujące znacznie poprawiają czytelność kodu. Zamiast długich konstruktorów z wieloma parametrami, oferujesz wyspecjalizowane, jasno nazwane punkty wejścia.

Dlaczego warto stosować Value Objects?

Głównym argumentem jest czytelność kodu. Twój kod zaczyna mówić językiem biznesu, a nie technologii. Wszystkie operacje związane z danym konceptem są zamknięte w jednej klasie. I ponownie nasuwa się tu analogia do Lego. Valu Object to wyspecjalizowany klocek, którego możemy użyć w wielu konstrukcjach.

Czy zauważyłeś, jak Value Objects mogą uprościć Twój kod? Może czas rozejrzeć się po własnych projektach i znaleźć miejsca, gdzie proste typy aż proszą się o zamianę na pełnoprawne obiekty domenowe?

Fasady w architekturze: jak chronić swoją domenę biznesową

Czy zastanawiałeś się kiedyś, jak skutecznie oddzielić logikę biznesową od reszty aplikacji? Wzorzec fasady może być Twoim orężem. Działa jak ochroniarz Twojej domeny – wpuszcza tylko zaproszonych gości i dba, by nikt nie naruszał wewnętrznych zasad.

Fasady tworzą elastyczną warstwę ochronną wokół Twojej domeny. Dzięki nim model jednej domeny nie przenika do drugiej. To jak budowanie mostu zwodzonego wokół zamku – kontrolujesz, co wchodzi i wychodzi.

Niestety, każda strategia ma swoją cenę. Musisz oddzielić klasy transportowe (część interfejsu fasady) od właściwych obiektów domenowych. Jak poradzić sobie z tym wyzwaniem?

Stosuję prostą zasadę: każdy Value Object może być częścią fasady. Agregaty natomiast pozostają wewnątrz domeny. 

Unikaj jednak nadmiernego rygoryzmu. Przepisywanie i transformowanie dużych, zagnieżdżonych obiektów transportowych (DTO) na Value Objects byłoby stratą czasu. Czasem pragmatyzm wygrywa z idealizmem.

Dwie twarze fasady

Fasady mają dwa zastosowania. Mogą służyć jako:

1. Interfejs do Twojej własnej domeny

2. Interfejs do zewnętrznej domeny, którą wykorzystujesz

Wyobraź sobie domenę bankową odpowiedzialną za przelewy i operacje kartowe. Możesz ją obudować fasadą "BankFacade". Ale co, jeśli Twoja domena zakupowa potrzebuje tylko inicjować płatności?

W takim przypadku stwórz dodatkowy serwis fasadowy w domenie zakupowej – "PaymentFacade". Będzie on tłumaczem między światem bankowości a zakupami. To jak zatrudnienie specjalisty, który zna oba języki i upraszcza komunikację.

Rozważmy EventBus. Jeśli chcesz poinformować system o zrealizowanym zakupie. Technicznie możesz użyć Kafki lub JMS. Jednak domenowo przedstawiasz to jako "Szynę Zdarzeń".

Ekspertowi domenowemu łatwiej zrozumieć pojęcie Szyny Zdarzeń niż szczegóły implementacyjne Kafki. Z twojej perspektywy kupujesz sobie czas na wybór odpowiedniej technologii a także opcję na jej zmianę przyszłości.

Fasady spełniają dwie kluczowe role:

- Upraszczają złożoność Twojej domeny dla zewnętrznego świata

- Tłumaczą zewnętrzne domeny na zrozumiały język w Twoim systemie

A Ty, jak wykorzystujesz fasady w swojej architekturze? Może stosujesz inne wzorce do separacji domen? Podziel się swoimi doświadczeniami!

Kiedy "to zależy" zmienia się w kod – odkrywanie potencjału polityk domenowych

Czy słyszałeś kiedyś "to zależy" podczas rozmowy o wymaganiach? Ta odpowiedź to nie przeszkoda – to sygnał do działania! Właśnie odkryłeś idealne miejsce do zastosowania polityki domenowej.

Polityka domenowa to odpowiednik wzorca strategii przeniesiony do języka domeny. Wyobraź sobie ją jako zestaw reguł decyzyjnych, który możesz wymienić jak kasety w starym magnetofonie. Każda kaseta gra inną melodię, ale pasuje do tego samego odtwarzacza.

Kiedy napotkasz sytuację "to zależy", zadaj sobie dwa proste pytania: od czego zależy decyzja? Jaki ma efekt? Odpowiedzi pomogą Ci zdefiniować interfejs polityki.

Jak wprowadzić politykę do kodu?

Zacznij od zdefiniowania interfejsu opisującego decyzję. Zastanów się jakie parametry wpływają na podejmowaną decyzję i co jest jej wynikiem.  Potraktuj to jak kontrakt, który określa dane wejściowe i oczekiwany rezultat. Następnie stwórz konkretne implementacje dla różnych scenariuszy.

Czy wiesz, że politykę możesz dostarczyć na wiele sposobów? Możesz ją przekazać bezpośrednio, wytworzyć w serwisie domenowym, uczynić częścią agregatu lub udostępnić przez fasadę zewnętrznego serwisu.

Polityka to nie tylko element projektu – to żywa dokumentacja. Pokazuje jasno, jakie decyzje podejmujesz w systemie, kiedy je stosujesz i co na nie wpływa. Dzięki temu nowi członkowie zespołu szybciej zrozumieją logikę biznesową.

Czy stosujesz już polityki domenowe w swoich projektach? A może zainspiruje Cię to do przejrzenia kodu i znalezienia miejsc, gdzie "to zależy" mogłoby przekształcić się w elegancki, wymienialny mechanizm decyzyjny?

Dwa oblicza błędów w systemach IT – jak skutecznie zarządzać awariami w duchu DDD?

Czy kiedykolwiek zastanawiałeś się, ile rzeczy może pójść nie tak w Twoim systemie? 

W świecie DDD zarządzanie błędami to nie tylko kwestia techniczna, ale przede wszystkim biznesowa. Przewidzenie każdej możliwej awarii jest niemal niemożliwe. Zamiast tego warto skupić się na tym, jak system powinien się zachowywać, kiedy pojawia się problem.

Z perspektywy modelu domenowego wszystkie błędy można podzielić na dwie kategorie: błędy biznesowe, które wynikają ze specyfiki reguł i ograniczeń biznesowych, oraz błędy techniczne – nieoczekiwane sytuacje, które system musi obsłużyć w sposób spójny i przewidywalny.

Błędy biznesowe w DDD 

Błędy biznesowe to nic innego jak ograniczenia w modelu domenowym, które jasno definiują, co jest dozwolone, a co nie. Dzięki temu klient otrzymuje precyzyjne i zrozumiałe komunikaty, które odzwierciedlają rzeczywiste zasady biznesowe. W DDD to ekspert domenowy decyduje, jak system ma reagować na takie sytuacje – to właśnie on projektuje reguły i granice, które system musi respektować.

Wyjątki biznesowe modeluję zawsze jawnie (checked exception). Są one dobrze widoczne na poziomie serwisów domenowych i wspólnie z ekspertem modelujemy ustalamy właściwą reakcję procesu.

To podejście zwiększa czytelność kodu i sprawia, że błędy biznesowe stają się naturalną częścią modelu, a nie niespodziewanym wyjątkiem.

Błędy techniczne

Błędy techniczne to wszelkie nieprzewidziane wyjątki, które nie powinny wpływać na model domenowy. Zazwyczaj aby dobrze zrozumieć problem i naturę awarii technicznej sprowadzam ją do przysłowiowego wyłączenia wtyczki z prądem. 

W moich projektach sprawdza się modelowanie wszystkich awarii technicznych w formie błędów niejawnych (unchecked exception). Po pierwsze błędy techniczne nie zaciemniają modelu, a po drugie jeśli dzieje się coś niepożądanego w procesie chcę aby natychmiast się on zakończył.

Spójna obsługa błędów technicznych, niezależnie od ich źródła, pomaga w utrzymaniu stabilności systemu i umożliwia efektywne reagowanie na awarie.

Podsumowanie – jak tworzyć kod, który naprawdę wspiera biznes

Chcesz, aby Twój kod nie tylko działał, ale też opowiadał historię biznesu? To możliwe! W świecie nowoczesnego programowania kontrakt to coś więcej niż tylko techniczny interfejs, a wartość to nie tylko liczba z przecinkiem. Stosując podejście Domain-Driven Design (DDD), możesz tworzyć systemy, które „oddychają” logiką biznesową i komunikują się w sposób zrozumiały dla wszystkich interesariuszy.

Zachęcam Cię do eksperymentowania z DDD w swoich projektach — zobaczysz, jak Twój kod nabiera życia i zyskuje na przejrzystości. Rozdzielanie błędów biznesowych od technicznych oraz świadome zarządzanie reakcjami systemu to klucz do budowania stabilnych i odpornych na awarie aplikacji. 

Jeśli zainteresował Cię ten temat i chcesz o nim porozmawiać, zapraszam do kontaktu – znajdziesz mnie na LinkedIn. 

Powodzenia w tworzeniu kodu, który oddycha biznesem! 🙂