Szkolenie PHP – Od monolitu do architektury modularnej
Poziom
ZaawansowanyCzas
16h / 2 dniTermin
IndywidualnieCena
IndywidualnieSzkolenie PHP – Od monolitu do architektury modularnej
Warsztat uczy projektowania systemów — nie od zera, ale przez ewolucję istniejącego kodu. Uczestnicy otrzymują działający monolit e-commerce i przeprojektowują go krok po kroku: identyfikują ukryte sprzęganie, wyodrębniają bounded contexty metodą EventStorming, a następnie fizycznie rozdzielają kod na moduły z wymuszonymi granicami. Każda zmiana jest inkrementalna i weryfikowalna — deptrac pilnuje granic, testy chronią przed regresją, a GitHub Actions automatyzują kontrolę jakości. Warsztat kończy się modularnym monolitem z czytelnymi kontekstami, zdarzeniami domenowymi i CI pipeline’em, który nie pozwoli na ponowne sprzęgnięcie kodu.
Dla kogo jest to szkolenie?
Absolwentów warsztatu PHP Podstawy + Zaawansowany, gotowych na poziom architektoniczny-
Developerów PHP z doświadczeniem komercyjnym, którzy potrafią samodzielnie zbudować REST API z testami
-
Programistów pracujących z monolitami, w których „zmiana w jednym miejscu psuje trzy inne”
-
Zespołów, które chcą wprowadzić modularność do istniejących aplikacji bez przepisywania od zera
Czego nauczysz się na tym szkoleniu?
Analizowania zależności w istniejącym kodzie przy pomocy deptrac-
EventStorming jako metody odkrywania domeny i wyodrębniania bounded contextów
-
Domain-Driven Design (strategic + tactical) — Ubiquitous Language, agregaty, zdarzenia domenowe
-
Refaktoryzacji monolitu w modularny monolit z wymuszonymi granicami między modułami
-
Komunikacji między modułami przez zdarzenia domenowe (Symfony EventDispatcher)
-
Egzekwowania granic architektonicznych — deptrac jako CI guard
-
Dokumentowania decyzji architektonicznych (ADR — Architecture Decision Records)
-
Konfigurowania CI pipeline (GitHub Actions) z deptrac, PHPUnit i PHPStan
Wymagania
- PHP 8.3+: programowanie obiektowe, interfejsy, dependency injection
- Testy PHPUnit: unit i integracyjne
- Znajomość SRP i DIP — umiejętność wyjaśnienia na przykładzie ze swojego kodu
- REST API z Symfony Components lub pełnym frameworkiem (Symfony/Laravel)
- Docker i Composer
Program szkolenia
Dzień 1
Etap 1: Anatomia problemu
- Przegląd zastanego monolitu — co działa, co boli, gdzie są ukryte zależności
- Czytanie logów (structured logging) — zrozumienie przepływu danych
- deptrac — generowanie mapy zależności między klasami
- Identyfikacja ukrytego sprzęgania — „dlaczego zmiana w katalogu psuje zamówienia?”
- Efekt: Uczestnicy widzą mapę zależności monolitu i rozumieją, gdzie są problemy
Etap 2: DDD — strategic design
- EventStorming — kolaboracyjne odkrywanie domeny, identyfikacja zdarzeń biznesowych, komend i agregatów
- Ubiquitous Language — dlaczego „produkt” znaczy co innego w katalogu, koszyku i magazynie
- Bounded Contexts — wyodrębnianie granic (Catalog, Cart, Order) na podstawie wyników EventStorming
- Efekt: Monolit jest koncepcyjnie podzielony na konteksty; uczestnicy rozumieją DLACZEGO te granice, nie tylko GDZIE
Dzień 2
Etap 3: DDD tactical + Modularny monolit
Teoria i praktyka przeplatane w cyklach: zidentyfikuj → wyodrębnij → zweryfikuj.
- Cykl 1 — Pierwszy moduł: Catalog
- Struktura katalogów — src/Catalog/ jako samodzielna jednostka
- Publiczne API modułu — interfejsy jako kontrakt; implementacja ukryta
- Przeniesienie kodu katalogowego do modułu
- deptrac — dodanie pierwszej reguły, weryfikacja granicy
- Cykl 2 — Drugi moduł: Order + komunikacja
- Agregaty — modelowanie reguł biznesowych, które bronią się same
- Zdarzenia domenowe — OrderPlaced jako kontrakt między kontekstami
- Komunikacja między modułami — Symfony EventDispatcher
- Internal vs Published events — nie każde zdarzenie jest publiczne
- Cykl 3 — Weryfikacja i egzekwowanie
- deptrac jako CI guard — pełna konfiguracja
- Testowanie modułowe — testy integracyjne modułu w izolacji
- Cart jako ćwiczenie — uczestnicy wyodrębniają trzeci moduł samodzielnie
- Efekt: Kod jest fizycznie podzielony na moduły z wymuszonymi granicami i komunikacją przez eventy
Etap 4: Architektura na co dzień
- ADR (Architecture Decision Records) — dokumentowanie decyzji architektonicznych
- Fitness functions — GitHub Actions z deptrac, PHPUnit i PHPStan jako automated quality gate
- Kiedy NIE robić DDD/modularyzacji — over-engineering to też anty-wzorzec
- Retrospektywa — co się zmieniło w monolicie, czego się nauczyliśmy
- Efekt: Uczestnicy mają framework decyzyjny i CI pipeline, nie tylko wiedzę techniczną
