Szkolenie Domain-Driven Design

Pomagamy zespołom lepiej projektować złożone systemy, porządkować architekturę i podejmować trafniejsze decyzje techniczne. Szkolenie z Domain-Driven Design jest nastawione na praktykę — pokazujemy nie tylko czym jest DDD, ale przede wszystkim jak wykorzystać je w realnym projekcie, kiedy ma sens i jak uniknąć niepotrzebnej złożoności.

Strategic DDD — uporządkuj domenę zanim zaczniesz projektować system

Zaczynamy od spojrzenia na system z perspektywy biznesu. Pokazujemy, jak identyfikować najważniejsze obszary domeny, wyznaczać granice odpowiedzialności i dzielić duży system na logiczne części.

Uczestnicy uczą się, jak pracować z:

• Domain i Subdomain,
• Core Domain,
• Ubiquitous Language,
• Bounded Context,
• Context Mapping,
• relacjami pomiędzy kontekstami.

Celem jest stworzenie architektury, która odzwierciedla rzeczywiste procesy biznesowe, zamiast przypadkowego podziału na moduły, serwisy czy tabele.

Tactical DDD — przenieś reguły biznesowe do dobrze zaprojektowanego modelu

W kolejnej części pokazujemy, jak zbudować model domenowy, który jest czytelny, odporny na zmiany i chroni najważniejsze reguły biznesowe.

Pracujemy m.in. z:

• Entity,
• Value Object,
• Aggregate,
• Aggregate Root,
• Repository,
• Domain Service,
• Domain Event,
• Factory.

Nie uczymy wzorców dla samych wzorców. Pokazujemy, kiedy warto ich używać, jak je łączyć i kiedy prostsze rozwiązanie będzie lepsze.

Agregaty — jak wyznaczać dobre granice transakcyjne

Jednym z kluczowych tematów szkolenia jest prawidłowe modelowanie Aggregate.

Pokazujemy:

• jak dobierać granice agregatu,
• które reguły biznesowe powinny być chronione wewnątrz,
• jak uniknąć zbyt dużych agregatów,
• kiedy rozdzielać encje na osobne modele,
• jak projektować relacje pomiędzy agregatami,
• jak agregaty wpływają na transakcje, wydajność i współbieżność.

To szczególnie ważne w systemach, które z czasem rosną i zaczynają być trudne w utrzymaniu.

Hexagonal i Onion Architecture — oddziel logikę biznesową od technologii

Pokazujemy, jak połączyć DDD z Hexagonal Architecture i Onion Architecture, aby domena nie była zależna od frameworka, bazy danych czy konkretnego sposobu komunikacji.

Uczestnicy poznają praktyczny podział odpowiedzialności pomiędzy:

• Domain,
• Application,
• Infrastructure,
• Presentation,
• Ports & Adapters.

Dzięki temu łatwiej rozwijać system, testować logikę oraz wymieniać elementy infrastruktury bez przebudowy całej aplikacji.

CQRS — rozdziel odpowiedzialności i uprość model

Pokazujemy, jak wykorzystać CQRS razem z DDD i architekturą hexagonalną lub onion.

Wyjaśniamy:

• czym różnią się Commands i Queries,
• jak powinny wyglądać Command Handlers i Query Handlers,
• gdzie powinna znajdować się logika biznesowa,
• jak oddzielić write model od read model,
• kiedy CQRS daje realną wartość,
• kiedy niepotrzebnie komplikuje projekt.

Łączymy wszystkie elementy w spójny przepływ:

Controller → Command → Handler → Aggregate → Repository

oraz:

Controller → Query → Handler → Read Model

Domain Events i Event-Driven Architecture

Pokazujemy, jak wykorzystać zdarzenia domenowe do zmniejszenia sprzężeń pomiędzy modułami i usługami.

Omawiamy:

• Domain Events,
• Integration Events,
• Event Bus,
• Message Broker,
• eventual consistency,
• idempotency,
• retry,
• Outbox Pattern.

Dzięki temu uczestnicy rozumieją nie tylko jak budować systemy event-driven, ale także kiedy takie podejście faktycznie ma sens.

Kiedy DDD ma sens, a kiedy nie

DDD nie jest rozwiązaniem dla każdego projektu. Dlatego pokazujemy również, kiedy zastosowanie rozbudowanego modelu domenowego przynosi wartość, a kiedy prosty CRUD będzie znacznie lepszym wyborem.

Uczymy zespoły dobierać poziom architektury do realnej złożoności systemu, zamiast wdrażać wzorce mechanicznie.

Praca na realnych problemach

Szkolenie możemy prowadzić na przygotowanych przykładach albo oprzeć je na rzeczywistym systemie uczestników.

Możemy wspólnie przejść przez:

problem biznesowy → model domeny → Bounded Contexts → Aggregates → Commands → Events → architektura aplikacji

Dzięki temu zespół nie wychodzi ze szkolenia tylko z teorią, ale z konkretnym sposobem myślenia i narzędziami, które może wykorzystać od razu w projekcie.

Co zyskuje Twój zespół?

Po szkoleniu uczestnicy lepiej rozumieją, jak projektować granice systemu, modelować złożoną logikę biznesową i budować architekturę odporną na dalszy rozwój.

Celem nie jest wdrożenie maksymalnej liczby wzorców, ale nauczenie zespołu jak świadomie zarządzać złożonością i wybierać rozwiązania adekwatne do problemu.

Zakres szkolenia dopasowujemy do doświadczenia zespołu, obecnej architektury i konkretnych wyzwań projektu.