Domain-Driven Design (DDD) to podejście do projektowania oprogramowania, które skupia się na modelowaniu rzeczywistej domeny biznesowej. Głównym celem jest stworzenie aplikacji wiernie odzwierciedlającej zasady biznesu, przy ścisłej współpracy zespołu programistycznego z ekspertami domenowymi. DDD promuje też użycie wspólnego języka (ang. ubiquitous language), czyli zestawu pojęć ustalonych przez cały zespół, co pomaga unikać nieporozumień między działem biznesowym a kodem. W tym artykule przedstawię Ci najważniejsze założenia DDD oraz praktyczne wskazówki, jak zacząć to stosować w projektach .NET.
Kluczowe koncepcje DDD
W DDD podstawą jest model domeny, zbiór klas odzwierciedlających pojęcia biznesowe. W kodzie wyróżniamy kilka kluczowych ról:
• Encja (Entity): obiekt z unikalną tożsamością, który zmienia się w czasie, ale pozostaje rozpoznawalny (np. klasa Order z własnym Id). Każde zamówienie ma swój identyfikator, dzięki czemu jest łatwo śledzone w systemie.
• Obiekt wartości (Value Object): obiekt definiowany wyłącznie przez swoje atrybuty, bez osobnego Id. Przykładem jest adres czy kwota pieniężna, jeśli potrzebujemy innego adresu, tworzymy nowy obiekt. Takie obiekty są zazwyczaj niemutowalne (np. struktura Address).
• Agregat (Aggregate): grupa powiązanych obiektów domenowych (encje + obiekty wartościowe) traktowana jako całość ze wspólną spójnością. Agregat ma jedną Encję pełniącą rolę korzenia (ang. aggregate root), która kontroluje zmiany wewnątrz agregatu. Przykładowo Order może być korzeniem agregatu zawierającego listę OrderItem, tylko korzeń agregatu zapewnia spójność całego zamówienia.
• Wspólny język (Ubiquitous Language): ustalone nazewnictwo pojęć domenowych, używane we wszystkich częściach projektu (dokumentacja, rozmowy, kod). Dzięki niemu deweloperzy i analitycy mówią tym samym językiem, np. jeśli biznes operuje pojęciem Klient, klasa czy metoda w kodzie również noszą tę nazwę.
• Ograniczony kontekst (Bounded Context): wyraźnie wyodrębniony fragment systemu, w którym terminy mają spójne znaczenie. W dużej aplikacji możemy podzielić ją na moduły lub mikroserwisy (np. moduł Zamówienia, Magazyn, Księgowość), z których każdy ma własny model. Dzięki temu używając tych samych słów w różnych kontekstach unikamy kolizji pojęć.
Powyższe koncepcje pozwalają budować model domeny zbliżony do realnego problemu. DDD kładzie też nacisk na repozytoria (ukrywające dostęp do bazy danych) oraz usługi domenowe (operacje biznesowe niepasujące do pojedynczej encji), ale można je wprowadzać stopniowo.
public class Order
{
public Guid Id { get; }
public DateTime CreatedAt { get; }
public Order(Guid id)
{
Id = id;
CreatedAt = DateTime.Now;
}
}
public struct Address
{
public string City { get; }
public string Street { get; }
public Address(string city, string street)
{
City = city;
Street = street;
}
}Pierwsze kroki z DDD w .NET
1. Zrozum domenę i ustal wspólny język. Spotkaj się z ekspertami biznesowymi, wypisz kluczowe pojęcia i procesy. Zdefiniuj słownictwo, które będzie odzwierciedlać wymagania (np. Zamówienie, Klient, Status). DDD zakłada ścisłą współpracę z biznesem, dzięki temu Twoje klasy (encje, wartości itp.) będą miały sens w kontekście rzeczywistych potrzeb.
2. Zaprojektuj model domeny. Utwórz klasy Entity i obiekty wartości reprezentujące najważniejsze byty. Zastanów się, jakie agregaty są logiczne (np. Order z kolekcją OrderItem). Przy projektowaniu weź pod uwagę invariants i reguły, to one znajdą się w metodach Twoich klas domenowych. Dzięki takiemu modelowi kod będzie naturalnie odwzorowywał procesy biznesowe (np. tworzenie lub modyfikacja zamówienia, zmiana statusu).
3. Wprowadź warstwy i repozytoria. Utwórz oddzielną warstwę/domain library dla modeli domeny, a wewnątrz zdefiniuj interfejsy repozytoriów (np. IOrderRepository). Implementacje repozytoriów (np. korzystające z Entity Framework Core) umieść w warstwie infrastruktury. Dzięki temu separujesz logikę domenową od detali przechowywania danych, co ułatwia utrzymanie i testowanie aplikacji.
4. Testuj i rozwijaj model. Logikę osadzoną w modelu domeny łatwo pokryć testami jednostkowymi, to pomaga sprawdzić, czy biznesowe reguły działają poprawnie. W miarę poznawania nowych wymagań poprawiaj model, stosując zasady DDD. Nie trzeba od razu pełnego DDD, można zacząć od najważniejszych elementów i sukcesywnie wprowadzać kolejne wzorce (np. wzorzec usług domenowych, DDD-owe eventy) w miarę wzrostu złożoności projektu.
Podsumowanie
Domain-Driven Design pomaga tworzyć przejrzyste modele odpowiadające realnym procesom biznesowym. Właściwie zaprojektowany model domenowy zwykle ułatwia testowanie, rozwój i utrzymanie aplikacji, ponieważ kod realizuje konkretne pojęcia z dziedziny biznesu. Jednocześnie DDD wymaga czasu na zrozumienie domeny i ustalenie wspólnego języka, dlatego warto stosować je tam, gdzie złożoność biznesowa jest duża.
Jeśli planujesz budować rozbudowane aplikacje ASP.NET Core (MVC, Web API) i chcesz poznać dobre praktyki ich architektury (w tym modelowania domeny), zachęcam do mojego szkolenia Szkoła ASP.NET Core. To szkolenie pokazuje krok po kroku tworzenie dużej aplikacji webowej w ASP.NET Core z zaawansowaną architekturą, dzięki temu łatwiej będzie Ci wdrożyć zasady DDD w praktyce.
