Domain-Driven Design (DDD) to podejście do projektowania oprogramowania, które kładzie nacisk na ścisłą współpracę z ekspertami dziedziny, aby stworzyć model, który dokładnie odzwierciedla logikę biznesową. Zamiast skupiać się na technologii, DDD koncentruje się na zrozumieniu i modelowaniu złożonej domeny biznesowej. Chociaż DDD często kojarzone jest z architekturą, jest to przede wszystkim zestaw zasad i taktyk, które pomagają zespołom tworzyć oprogramowanie lepiej dopasowane do potrzeb biznesowych. Dwa kluczowe pojęcia, które pozwalają wprowadzić DDD w życie, to Bounded Contexts i Event Storming.
Bounded Contexts: granice i spójność
Bounded Context to centralna koncepcja w DDD. Jest to logiczna granica, wewnątrz której dany model domenowy jest spójny i ma jednoznaczne znaczenie. W świecie biznesowym te same terminy mogą mieć zupełnie inne znaczenie w zależności od kontekstu. Przykładowo, „Produkt” w systemie e-commerce może oznaczać coś innego dla działu sprzedaży (cena, promocje) niż dla działu magazynowego (lokalizacja, ilość na stanie).
Zrozumienie i zdefiniowanie tych granic jest kluczowe dla uniknięcia chaosu i błędów w komunikacji.
W praktyce Bounded Contexts manifestują się jako oddzielne aplikacje, mikroserwisy lub moduły. Każdy Bounded Context posiada własny model domenowy, własny kod i własne repozytoria danych. Komunikacja między nimi odbywa się poprzez jasno zdefiniowane interfejsy, takie jak API, kolejki wiadomości czy zdarzenia (events). To podejście zapewnia luźne powiązanie (loose coupling) i pozwala zespołom pracować nad swoimi kontekstami niezależnie, bez obawy o naruszenie spójności modelu w innej części systemu. Zespoły mogą decydować o technologii i architekturze wewnątrz swojego kontekstu, o ile zachowują zdefiniowane interfejsy komunikacji.
Na przykład, w systemie e-commerce możemy zdefiniować Bounded Contexty:
- Sprzedaż i Promocje: Zarządza koszykiem, zamówieniami i rabatami. „Produkt” w tym kontekście ma atrybuty takie jak cena, nazwa, opis i ewentualne promocje.
- Zarządzanie Magazynem: Zajmuje się stanem magazynowym, dostawami i lokalizacją produktów. „Produkt” tutaj ma atrybuty: unikalny numer, lokalizacja w magazynie i dostępna ilość.
- Księgowość i Fakturowanie: Tworzy faktury i zarządza płatnościami. „Produkt” jest tutaj pozycją na fakturze z ceną i podatkiem.
Oddzielenie tych kontekstów pozwala uniknąć sytuacji, w której zmiana modelu produktu w jednym miejscu wpływa na cały system.
Event Storming krok po kroku
Event Storming to technika warsztatowa, której celem jest szybkie odkrycie złożonej domeny biznesowej. Jest to potężne narzędzie, które angażuje ekspertów dziedziny i deweloperów do wspólnego modelowania. Pozwala ona na wizualizację przepływów biznesowych i identyfikację Bounded Contexts w sposób partycypacyjny.
Krok 1: Przygotowanie i wprowadzenie. Zbierz w jednym miejscu ekspertów dziedziny (osoby, które doskonale rozumieją, jak działa biznes), deweloperów, architektów i testerów. Przygotuj dużą, pustą ścianę i dużo karteczek samoprzylepnych w różnych kolorach. Każdy kolor będzie reprezentował inny typ zdarzenia lub komponentu.
Krok 2: Odkrywanie zdarzeń domenowych (Domain Events). To najważniejszy etap. Eksperci i deweloperzy wspólnie zapisują zdarzenia domenowe (Domain Events) na pomarańczowych karteczkach. Zdarzenie to coś, co już się wydarzyło w systemie, np. „ProduktDodanyDoKoszyka”, „ZamówienieZłożone”, „PłatnośćPrzyjęta”. Piszcie w czasie przeszłym. Zaczynamy od końca procesu i cofamy się w czasie, zadając sobie pytania typu: „Co musiało się stać, aby to się wydarzyło?”. Umieszczajcie karteczki na ścianie w kolejności chronologicznej, tworząc oś czasu.
Krok 3: Identyfikacja komend i aktorów. Po zebraniu zdarzeń, przechodzimy do identyfikacji, co spowodowało te zdarzenia. Używamy niebieskich karteczek dla komend (Commands), czyli poleceń, które doprowadziły do zdarzenia, np. „DodajProduktDoKoszyka”. Następnie identyfikujemy aktorów (Actors) – osoby lub systemy, które wydały te komendy, używając żółtych karteczek, np. „Klient”, „SystemERP”.
Krok 4: Definiowanie agregatów i odczytów. Czas na modelowanie. Agregat (fioletowa karteczka) to klaster obiektów, które są traktowane jako jedna całość. Np. Koszyk może być agregatem zawierającym LinieKoszyka. Komendy są wysyłane do agregatów, które generują zdarzenia. Dodaj zielone karteczki, aby pokazać, w jaki sposób użytkownicy odczytują dane (WidokKoszyka).
Krok 5: Wytyczanie Bounded Contexts. Po stworzeniu mapy zdarzeń i komend, zauważysz, że niektóre obszary są ze sobą ściśle powiązane, a inne są bardziej odseparowane. Używając dużych arkuszy papieru lub pisaków, narysuj granice wokół logicznie spójnych grup zdarzeń i agregatów. Te granice to właśnie Twoje Bounded Contexts.
Na przykład, zdarzenia związane z płatnościami i fakturowaniem będą w innym kontekście niż zdarzenia dotyczące magazynu.
DDD to nie tylko teoria, to praktyczny sposób na projektowanie oprogramowania, które rośnie wraz z biznesem. Zrozumienie Bounded Contexts pozwala na budowanie modułowych i niezależnych systemów. Event Storming natomiast jest potężną techniką, która demokratyzuje proces modelowania domeny, umożliwiając deweloperom i ekspertom domenowym wspólne tworzenie wizji. Stosując te dwie techniki, zespoły mogą przejść od myślenia o technologii do myślenia o realnych problemach biznesowych, tworząc systemy, które są bardziej elastyczne, łatwiejsze w utrzymaniu i dokładniej odzwierciedlają logikę biznesową.
