| Tytuł: | Czysta architektura i Domain-driven Design w Pythonie |
| Kod: | ddd-clean |
| Kategoria: | Architektura systemów i aplikacji |
| Forma: | 30% wykłady / 70% warsztaty |
| Czas trwania: | 3 dni |
| Odbiorcy: | developerzy, architekci |
| Zapisy: |
Indywidualne zamówienie i dopasowanie dla grupy. |
| Logistyka: |
W siedzibie klienta lub w innym dowolnym miejscu. |
Wprowadzenie do DDD i budowania modularnych aplikacji w Pythonie z wykorzystaniem czystej architektury.
Szkolenie oparte o studium przypadku.
Dzień 1: Wstęp do Domain-Driven Design i modularności - organizujemy projekt
Dzień 2: Wzorce taktyczne - czysta architektura + DDD - piszemy testowalny i łatwo utrzymywalny kod
Dzień 3: Zagadnienia przekrojowe, wstrzykiwanie zależności oraz CQRS - zajmujemy się tymi “przyziemnymi” problemami
Wyróżniki szkolenia
- Modularyzacja systemu
- Architektura systemowa i aplikacyjna
- Praktyczne zastosowanie DDD
Program Szkolenia
Program jest ramą w jakiej możemy się poruszać merytorycznie - program dla konkretnego szkolenia dedykowanego ustalamy z grupą na podstawie analizy przed-szkoleniowej.-
Wprowadzenie do Domain-Driven Design- Dlaczego potrzebujemy modularności?
- Utrzymywalność oprogramowania
- Skalowanie wytwarzania oprogramowania
- Łatwiejsze rozbijanie projektu na mniejsze
- Pogodzenie różnych perspektyw
- Pogodzenie różnych interesariuszy
- Utrzymywalność oprogramowania
- Jak DDD pomaga modularyzować
- Jeden model to z mało…
- …zamiast tego używamy kilku, wokół których organizujemy usługi / komponenty
- DDD, a organizacja zespołów
- Jeden model to z mało…
- Dlaczego potrzebujemy modularności?
-
DDD i modularność w praktyce - szukamy Bounded Contextów
- Poddomeny - problem space
- Bounded Contexty - solution space
- Heurystyki znajdowania Bounded Contextów
- Subdomeny
- Inni interesariusze
- Czy możemy to wyciągnąć i sprzedać osobno? Czy ktoś już to zrobił?
- Czy możemy znaleźć jedno źródło prawdy dla każdej informacji?
- Czy nie występują zjawiska data envy / feature envy?
- Czy używamy tych samych nazw na struktury w kodzie które działają inaczej (np. na modele)?
- Czy mylimy sposób działania biznesu z interfejsem użytkownika?
- Inne
- Subdomeny
- Budujemy mapę kontekstów
- Poddomeny - problem space
-
Budujemy modularny monolit na podstawie Bounded Contextów
- Dlaczego modularny monolit?
- Łatwe wdrożenie
- Tańsze eksperymenty i refaktoryzacja
- Łatwe wdrożenie
- Budowanie API dla komponentów
- Fasada
- Serwisy
- Przypadki użycia
- Komendy
- Zdarzenia
- Fasada
- Hermetyzacja komponentu
- Poza API zawartość pozostaje prywatna
- Poza API zawartość pozostaje prywatna
- Pilnowanie granic poprzez weryfikację importów i testy architektury
- pylint-forbidden-imports
- imports-linter
- pylint-forbidden-imports
- Sposoby integracji
- Wywoływanie API innego komponentu
- Port / Adapter
- Zdarzenia
- Asynchronicznie
- Synchronicznie
- Asynchronicznie
- Wywoływanie API innego komponentu
- Dlaczego modularny monolit?
-
Czysta architektura - wzorce taktyczne
- Przypadek użycia
- Często punkt startowy
- Logika orkiestracji
- Często punkt startowy
- Encje
- Logika biznesowa ważna w każdym kontekście
- Trzymają dane i pilnują poprawności
- Logika biznesowa ważna w każdym kontekście
- Repozytoria
- Zorientowane na persystencję
- Repozytoria - kolekcje
- Zorientowane na persystencję
- Porty
- Definicja “wtyczki” do logiki biznesowej
- Implementowana jako klasa abstrakcyjna
- Definicja “wtyczki” do logiki biznesowej
- Adaptery
- Implementacja “wtyczki” do logiki biznesowej
- Implementacja “wtyczki” do logiki biznesowej
- Przypadek użycia
-
DDD - wzorce taktyczne
- Agregaty
- Znajdowanie agregatów - heurystyki
- Powody stosowania agregatów
- Różnice między agregatem, a encją
- Znajdowanie agregatów - heurystyki
- Serwisy domenowe
- Kiedy odpowiedzialność nie pasuje do innego obiektu?
- Kiedy odpowiedzialność nie pasuje do innego obiektu?
- Polityki
- Zdarzenia domenowe
- Implementacja z użyciem DTO
- Implementacja z użyciem DTO
- Inne wzorce taktyczne
- Fabryka
- Process Manager / Saga
- Fabryka
- Agregaty
-
Kiedy nie stosować czystej architektury lub wzorców taktycznych DDD?
- Prosty problem
- Prototypowanie
- CRUD
- Proxy nad API firmy trzeciej
- Prosty problem
-
Rozwiązanie problemu zarządzania zależnościami
- Kontenery IoC i ich rola
- Inicjalizacja kontenera podczas uruchamiania aplikacji
- Inicjalizacja kontenera podczas uruchamiania aplikacji
- Przykłady dojrzałych narzędzi dostępnych w Pythonie
- Injector
- Dependency Injector
- Injector
- Zakresy (ang. scopes) w kontenerach IoC
- Singleton
- Threadlocal
- Context vars
- Singleton
- Dobre praktyki używania wstrzykiwania zależności
- Kod aplikacyjny nie wie nic o kontenerze IoC
- Nie używamy kontenera bezpośrednio (antywzorzec Service Locator)
- Nie wstrzykujemy zależności po to, by przekazać je dalej
- Nadal możemy łatwo nawigować po kodzie
- Kod aplikacyjny nie wie nic o kontenerze IoC
- Kontenery IoC i ich rola
-
Modularyzacja aplikacji z kontenerem IoC
- Zarządzanie konfiguracją
- Każdy komponent jako moduł kontenera IoC - składamy aplikację jak z klocków
- Wykorzystanie w testach
- Zarządzanie konfiguracją
-
CQRS
- Uzasadnienie modelu do odczytu
- Implementacja
- Stos do zapisu (ang. write stack)
- Command + Command Handler
- Wpływ na hermetyzację komponentu
- Command + Command Handler
- Stos do odczytu (ang. read stack)
- różnica tylko na poziomie kodu
- różnica na poziomie zapisu danych (kilka tabel/kolekcji/indeksów etc)
- różnica na poziomie bazy danych (kilka baz danych)
- różnica tylko na poziomie kodu
- Stos do zapisu (ang. write stack)
- Uzasadnienie modelu do odczytu
Pobierz program w formacie PDF
Trenerzy
Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.
