Szkolenie Domain Driven Design
Poziom
ŚredniozaawansowanyCzas
16h / 2 dniTermin
IndywidualnieCena
IndywidualnieSzkolenie z Domain Driven Design
Domain Driven Design to podejście do projektowania systemów, które kładzie duży nacisk na jak najlepsze odzwierciedlenie procesów i założeń biznesowych w implementacji. Obiekty i ich relacje powinny jak najbardziej odzwierciedlać biznes, a nazewnictwo powinno być spójne z językiem biznesowym. DDD daje nam narzędzia, struktury i terminologię, które możemy wykorzystać w procesie podejmowania decyzji projektowych. Jest zestawem koncepcji i technik wspierających projektowanie i implementację modeli biznesowych. Szkolenie oparte jest na rzeczywistych przykładach i praktycznym zastosowaniu, dzięki czemu uczestnicy rozbudują swoją wiedzę teoretyczną oraz udoskonalą umiejętność modelowania strategicznego i taktycznego. Uczestnicy uczą się także, jak wykorzystywać DDD do budowania wspólnego języka z biznesem oraz jak świadomie projektować granice systemów i odpowiedzialności.
Dla kogo jest szkolenie z Domain Driven Design?
Programiści, projektanci, product ownerzy, którzy pragną poznać praktycznie i przećwiczyć projektowanie złożonych modeli domen z wykorzystaniem Domain Driven Design-
Architekci systemowi i senior developerzy pracujący nad złożonymi systemami
-
Analitycy i osoby współpracujące z biznesem przy definiowaniu domeny i wymagań
Czego nauczysz się na szkoleniu?
- Zrozumiesz w jaki sposób Domain Driven Design pomaga w projektowaniu systemu informatycznego
- Nauczysz się zastosowania technik z poziomu wzorców taktycznych w obrębie Bounded Context
- Dowiesz się jak prawidłowo zastosować myślenie strategiczne (strategic thinking) podczas budowania systemu informatycznego
- Zrozumiesz znaczenie zdarzeń domenowych (Domain Events) i sposobu, w jaki mogą być użyte w integracji Bounded Contexts
- Identyfikować bounded contexty oraz subdomeny i rozumieć ich wpływ na architekturę systemu
- Wykorzystywać DDD do podejmowania decyzji architektonicznych i redukcji ryzyka w systemach
Program szkolenia z Domain Driven Design
Wprowadzenie do Domain Driven Design
- Problem dopasowania software’u do biznesu
- Czym DDD jest, a czym nie jest
- Kiedy DDD ma sens (i kiedy jest overkillem)
Ubiquitous Language w praktyce
- Budowanie wspólnego języka z biznesem
- Jak wykrywać niejednoznaczności i konflikty pojęć
- Język jako narzędzie projektowe, nie dokumentacyjne
- Antywzorce komunikacyjne
Perspektywa biznesowa i zrozumienie domeny
- Typy domen: Core, Supporting, Generic
- Wartość biznesowa jako driver decyzji architektonicznych
- Identyfikacja kluczowych obszarów systemu
- DDD jako narzędzie redukcji ryzyka
Wzorce strategiczne Domain Driven Design
- Bounded Context i granice odpowiedzialności
- Identyfikacja kontekstów i subdomen
- Context Map i relacje między kontekstami
- Monolit modularny vs mikroserwisy
- Ewolucja granic
DDD a architektura systemu
- Warstwy vs podejście heksagonalne
- Granice kontekstów a granice deployowalne
- Trade-offy architektoniczne
DDD strategiczne + AI
- Jak AI wpływa na odkrywanie domeny
- Wspieranie eksploracji domeny
- Ryzyko utraty kontekstu biznesowego
- AI jako wsparcie komunikacji z biznesem
Wprowadzenie do modelowania taktycznego
- Rola modelu domenowego w kodzie
- Anemiczny model vs bogaty model
- Gdzie powinna żyć logika biznesowa
Building blocks DDD
- Entity i tożsamość
- Value Object i niemutowalność
- Aggregate jako granica spójności
- Domain Event jako nośnik zmiany
- Repository i Factory
Projektowanie agregatów
- Invarianty i ich ochrona
- Heurystyki wyznaczania granic agregatu
- Konsystencja vs skalowalność
- Najczęstsze błędy (zbyt duże / zbyt małe agregaty)
Implementacja modelu domenowego
- Mapowanie modelu na kod
- Separacja modelu domenowego od infrastruktury
- ORM vs podejście domain-first
- Walidacja: gdzie i dlaczego
Testowanie w DDD
- Testy domeny vs testy integracyjne
- Testowanie agregatów
- Testy jako ochrona modelu
- Wpływ testów na design
DDD taktyczne + AI
- Generowanie kodu domenowego z AI
- Ryzyko anemicznego modelu
- Jak walidować kod generowany przez AI
- Testy jako mechanizm kontroli jakości AI
Powiązane podejścia architektoniczne
- CQRS jako separacja odpowiedzialności
- Event Sourcing – kiedy ma sens
- Event Driven Architecture
- Jak nie popaść w overengineering
DDD, a rozwój projektu
- Współpraca z biznesem na co dzień
- Utrzymywanie modelu w czasie
- Refaktoryzacja modelu domenowego
Wzorce uzupełniające
- Domain Services – kiedy logika nie pasuje do encji
- Policies – modelowanie reguł biznesowych
- Specification – kompozycja logiki
- Saga – koordynacja procesów rozproszonych
Najczęstsze błędy i antywzorce
- DDD jako “nazewnictwo klas”
- Brak granic kontekstów
- Nadmierna złożoność
- Brak współpracy z biznesem
