DDD
DDD (ang. Domain-Driven Design, projektowanie sterowane domeną) to podejście do tworzenia oprogramowania, w którym struktura i język kodu odzwierciedlają domenę biznesową — czyli obszar problemów, jakie system rozwiązuje. Sformułowane przez Erica Evansa w 2003 roku, zakłada ścisłą współpracę programistów z ekspertami dziedzinowymi oraz budowę modelu, który obie strony rozumieją tak samo.
Na czym polega Domain-Driven Design?
DDD dzieli się na dwie warstwy. Projektowanie strategiczne porządkuje duży system: wspólny język (ubiquitous language) wymusza te same pojęcia w rozmowach, dokumentacji i kodzie; bounded context wyznacza granice, w których dany model obowiązuje (inaczej „klient” rozumie moduł sprzedaży, inaczej windykacji); mapy kontekstów opisują relacje między nimi. Projektowanie taktyczne dostarcza klocków wewnątrz kontekstu: encje (obiekty z tożsamością), obiekty wartości (niezmienne, porównywane po atrybutach), agregaty (spójne grupy obiektów ze wspólnym korzeniem i regułami), repozytoria, usługi domenowe oraz zdarzenia domenowe rejestrujące fakty biznesowe. Logika biznesowa mieszka w modelu domenowym, a nie w kontrolerach czy warstwie bazy danych — framework jest szczegółem infrastruktury, wymienialnym bez naruszania reguł biznesowych.
Zastosowanie w praktyce
DDD sprawdza się w systemach o złożonej, zmiennej logice: bankowości, ubezpieczeniach, logistyce, rozliczeniach czy dużych platformach e-commerce. Praktyczne korzyści:
- granice bounded contextów wprost wyznaczają podział na moduły lub mikroserwisy i zakresy odpowiedzialności zespołów;
- wspólny język skraca dystans między biznesem a kodem — wymagania tłumaczą się na model niemal 1:1;
- agregaty i zdarzenia domenowe ułatwiają utrzymanie spójności danych i audytowalność;
- czysty model domenowy dobrze współgra z TDD, bo reguły biznesowe testuje się bez infrastruktury.
Warto jednak dobierać skalę środków do problemu: w prostych aplikacjach CRUD pełne DDD bywa przerostem formy nad treścią, a największą wartość dają wtedy same praktyki strategiczne — wspólny język i świadome granice kontekstów.
Powiązane pojęcia
Najczęstsze pytania
Czy DDD ma sens w każdym projekcie?
Nie — pełne DDD opłaca się przy złożonej logice biznesowej, która stanowi o przewadze produktu. W prostych aplikacjach CRUD narzut modelowania przewyższa korzyści; wtedy warto stosować co najwyżej strategiczne elementy, jak wspólny język i podział na konteksty.
Czym różni się DDD od architektury mikroserwisów?
DDD to metoda modelowania domeny, a mikroserwisy to styl wdrażania systemu — pojęcia niezależne, ale dobrze się uzupełniające. Bounded contexty z DDD są naturalnymi kandydatami na granice usług, dlatego DDD często poprzedza sensowny podział na mikroserwisy.
