Backend

Szkolenie 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.

Czas trwania
16h / 2 dni · 2h
Zapytaj o program → Zobacz wszystkie
Dla kogo

Idealny dla zespołów, które…

1 Programiści, projektanci, product ownerzy, którzy pragną poznać praktycznie i przećwiczyć projektowanie złożonych modeli domen z wykorzystaniem Domain Driven Design
2 Architekci systemowi i senior developerzy pracujący nad złożonymi systemami
3 Analitycy i osoby współpracujące z biznesem przy definiowaniu domeny i wymagań
Efekty po programie

Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.

✓

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 · 16 modułów

Co konkretnie robimy

M01
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)
M02
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
M03
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
M04
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
M05
DDD a architektura systemu
  • · Warstwy vs podejście heksagonalne
  • · Granice kontekstów a granice deployowalne
  • · Trade-offy architektoniczne
M06
DDD strategiczne + AI
  • · Jak AI wpływa na odkrywanie domeny
  • · Wspieranie eksploracji domeny
  • · Ryzyko utraty kontekstu biznesowego
  • · AI jako wsparcie komunikacji z biznesem
M07
Wprowadzenie do modelowania taktycznego
  • · Rola modelu domenowego w kodzie
  • · Anemiczny model vs bogaty model
  • · Gdzie powinna żyć logika biznesowa
M08
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
M09
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)
M10
Implementacja modelu domenowego
  • · Mapowanie modelu na kod
  • · Separacja modelu domenowego od infrastruktury
  • · ORM vs podejście domain-first
  • · Walidacja: gdzie i dlaczego
M11
Testowanie w DDD
  • · Testy domeny vs testy integracyjne
  • · Testowanie agregatów
  • · Testy jako ochrona modelu
  • · Wpływ testów na design
M12
DDD taktyczne + AI
  • · Generowanie kodu domenowego z AI
  • · Ryzyko anemicznego modelu
  • · Jak walidować kod generowany przez AI
  • · Testy jako mechanizm kontroli jakości AI
M13
Powiązane podejścia architektoniczne
  • · CQRS jako separacja odpowiedzialności
  • · Event Sourcing – kiedy ma sens
  • · Event Driven Architecture
  • · Jak nie popaść w overengineering
M14
DDD, a rozwój projektu
  • · Współpraca z biznesem na co dzień
  • · Utrzymywanie modelu w czasie
  • · Refaktoryzacja modelu domenowego
M15
Wzorce uzupełniające
  • · Domain Services – kiedy logika nie pasuje do encji
  • · Policies – modelowanie reguł biznesowych
  • · Specification – kompozycja logiki
  • · Saga – koordynacja procesów rozproszonych
M16
Najczęstsze błędy i antywzorce
  • · DDD jako “nazewnictwo klas”
  • · Brak granic kontekstów
  • · Nadmierna złożoność
  • · Brak współpracy z biznesem
Każdy moduł modyfikujemy pod Twój stack i kontekst. Powyższe to punkt wyjścia — nie sztywna agenda.
Jak pracujemy

Od briefu do retro w 30 dniach.

01

Brief i diagnoza

Rozmowa z liderem zespołu + krótka ankieta dla uczestników. Określamy cele, gap, kontekst.

02

Modyfikacja programu

Dostosowujemy moduły, case studies i przykłady kodu pod Twój stack. Akceptacja w 5 dni.

03

Warsztat

Sesje z trenerem, hands-on, code review. Mentor dostępny też pomiędzy sesjami.

04

Retro + raport

Raport z efektami dla zespołu i lidera. 30 dni konsultacji w cenie.

Zapytanie

Wyślij brief. Odezwiemy się w 1 dzień.

Po krótkim briefie przygotujemy program i wycenę. Bez zobowiązań — to tylko punkt wyjścia do rozmowy.

✓Wycena w 48h od briefu
✓Pierwsza sesja w 30 dni
✓Pilotaż przed pełną decyzją
✓Faktura VAT, możliwość płatności w transzach

Ochrona antyspamowa (Cloudflare Turnstile) zostanie aktywowana po wpięciu klucza.

Inne programy dla zespołów

Zobacz wszystkie →
Backend

Architektura systemów przez pryzmat czynnika ludzkiego

Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.

3 godziny →
Backend

Czysta Architektura

Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.

3 godziny →
Backend

Mikro, makro i wszystko pomiędzy: jak podejmować decyzje o wielkości serwisu

Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.

3 godziny →