Definicja #
DDD (Domain-Driven Design) to filozofia i zestaw wzorców architektonicznych do projektowania oprogramowania skupiający się na modelu domeny biznesowej jako centralnym elemencie systemu. Opisane przez Erica Evansa w książce Domain-Driven Design: Tackling Complexity in the Heart of Software (2003).
DDD dzieli się na dwa poziomy:
Strategic Design (wzorce strategiczne):
- Ubiquitous Language — wspólny język między programistami a ekspertami domenowymi
- Bounded Context — wyraźna granica, w której dany model i język mają jednoznaczne znaczenie
- Context Map — mapa relacji między Bounded Contexts
Tactical Design (wzorce taktyczne):
- Entity — obiekt z tożsamością (ID)
- Value Object — obiekt bez tożsamości, definiowany przez wartości
- Aggregate — klaster encji z jednym korzeniem (Aggregate Root)
- Domain Event — zdarzenie domenowe rejestrujące fakt biznesowy
- Repository — abstrakcja persystencji agregatów
- Domain Service — logika biznesowa nieprzynależna do encji
Zastosowania #
DDD stosuje się do:
- Projektowania złożonych systemów biznesowych z bogatą logiką domenową (fintech, e-commerce, logistyka)
- Architektury mikroserwisów — Bounded Contexts wyznaczają naturalne granice serwisów
- Refaktoringu dużych monolitów — identyfikacja granic przez Event Storming
- Komunikacji między zespołami technicznymi a biznesem — Ubiquitous Language redukuje nieporozumienia
- Projektowania API — zasoby i operacje odzwierciedlają język domeny biznesowej
Ścieżka nauki #
DDD jest tematem zaawansowanym — przed jego nauką warto mieć doświadczenie w programowaniu obiektowym i architekturze aplikacji.
Zacznij od:
- Przeczytaj Domain-Driven Design Erica Evansa (niebieska książka) lub Implementing DDD Vaughna Vernona
- Zrozum różnicę Entity vs Value Object
- Concept Aggregate Root i invariants
- Warsztaty Event Storming — odkrywanie domeny z ekspertami
Następnie poznaj:
- Bounded Contexts i Context Map — wzorce integracji: Anti-Corruption Layer, Shared Kernel
- CQRS (Command Query Responsibility Segregation) i Event Sourcing jako dopełnienie DDD
- Hexagonal Architecture (Ports and Adapters) — izolacja domeny od infrastruktury
- Praktyczne implementacje: przykłady w wybranym języku (Java, C#, Go)
FAQ #
- Czy DDD jest potrzebne w każdym projekcie?
- Nie. DDD jest najbardziej wartościowe w złożonych domenach biznesowych z bogatą logiką. W prostych aplikacjach CRUD, portalach content lub mikroserwisach z minimalną logiką DDD może być przerostem formy nad treścią — wprowadza dodatkową złożoność.
- Czym jest Ubiquitous Language w DDD?
- Ubiquitous Language to wspólny, precyzyjny słownik pojęć używany zarówno przez programistów, jak i ekspertów domenowych. Terminy z tego języka powinny pojawiać się bezpośrednio w kodzie (nazwy klas, metod, zmiennych), eliminując tłumaczenie między językiem biznesu a technicznym.
- Jak DDD ma się do mikroserwisów?
- Bounded Context z DDD jest naturalnym kandydatem na granicę mikroserwisu — każdy serwis odpowiada za jedną subdomenę z własnym modelem i językiem. DDD dostarcza metodologii do identyfikacji tych granic, co jest jednym z najtrudniejszych aspektów architektury mikroserwisów.
- Ile zarabia architekt znający DDD?
- DDD jest umiejętnością seniorów i architektów. Senior Software Engineer lub Software Architect z DDD zarabia w Polsce od 18 000 do 30 000+ zł brutto, w zależności od specjalizacji i branży.