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.

  1. Wprowadzenie do Domain-Driven Design
    1. Dlaczego potrzebujemy modularności?
      1. Utrzymywalność oprogramowania
      2. Skalowanie wytwarzania oprogramowania
      3. Łatwiejsze rozbijanie projektu na mniejsze
      4. Pogodzenie różnych perspektyw
      5. Pogodzenie różnych interesariuszy
    2. Jak DDD pomaga modularyzować
      1. Jeden model to z mało…
      2. …zamiast tego używamy kilku, wokół których organizujemy usługi / komponenty
      3. DDD, a organizacja zespołów
  2. DDD i modularność w praktyce - szukamy Bounded Contextów
    1. Poddomeny - problem space
    2. Bounded Contexty - solution space
    3. Heurystyki znajdowania Bounded Contextów
      1. Subdomeny
      2. Inni interesariusze
      3. Czy możemy to wyciągnąć i sprzedać osobno? Czy ktoś już to zrobił?
      4. Czy możemy znaleźć jedno źródło prawdy dla każdej informacji?
      5. Czy nie występują zjawiska data envy / feature envy?
      6. Czy używamy tych samych nazw na struktury w kodzie które działają inaczej (np. na modele)?
      7. Czy mylimy sposób działania biznesu z interfejsem użytkownika?
      8. Inne
    4. Budujemy mapę kontekstów
  3. Budujemy modularny monolit na podstawie Bounded Contextów
    1. Dlaczego modularny monolit?
      1. Łatwe wdrożenie
      2. Tańsze eksperymenty i refaktoryzacja
    2. Budowanie API dla komponentów
      1. Fasada
      2. Serwisy
      3. Przypadki użycia
      4. Komendy
      5. Zdarzenia
    3. Hermetyzacja komponentu
      1. Poza API zawartość pozostaje prywatna
    4. Pilnowanie granic poprzez weryfikację importów i testy architektury
      1. pylint-forbidden-imports
      2. imports-linter
    5. Sposoby integracji
      1. Wywoływanie API innego komponentu
      2. Port / Adapter
      3. Zdarzenia
        1. Asynchronicznie
        2. Synchronicznie
  4. Czysta architektura - wzorce taktyczne
    1. Przypadek użycia
      1. Często punkt startowy
      2. Logika orkiestracji
    2. Encje
      1. Logika biznesowa ważna w każdym kontekście
      2. Trzymają dane i pilnują poprawności
    3. Repozytoria
      1. Zorientowane na persystencję
      2. Repozytoria - kolekcje
    4. Porty
      1. Definicja “wtyczki” do logiki biznesowej
      2. Implementowana jako klasa abstrakcyjna
    5. Adaptery
      1. Implementacja “wtyczki” do logiki biznesowej
  5. DDD - wzorce taktyczne
    1. Agregaty
      1. Znajdowanie agregatów - heurystyki
      2. Powody stosowania agregatów
      3. Różnice między agregatem, a encją
    2. Serwisy domenowe
      1. Kiedy odpowiedzialność nie pasuje do innego obiektu?
    3. Polityki
    4. Zdarzenia domenowe
      1. Implementacja z użyciem DTO
    5. Inne wzorce taktyczne
      1. Fabryka
      2. Process Manager / Saga
  6. Kiedy nie stosować czystej architektury lub wzorców taktycznych DDD?
    1. Prosty problem
    2. Prototypowanie
    3. CRUD
    4. Proxy nad API firmy trzeciej
  7. Rozwiązanie problemu zarządzania zależnościami
    1. Kontenery IoC i ich rola
      1. Inicjalizacja kontenera podczas uruchamiania aplikacji
    2. Przykłady dojrzałych narzędzi dostępnych w Pythonie
      1. Injector
      2. Dependency Injector
    3. Zakresy (ang. scopes) w kontenerach IoC
      1. Singleton
      2. Threadlocal
      3. Context vars
    4. Dobre praktyki używania wstrzykiwania zależności
      1. Kod aplikacyjny nie wie nic o kontenerze IoC
      2. Nie używamy kontenera bezpośrednio (antywzorzec Service Locator)
      3. Nie wstrzykujemy zależności po to, by przekazać je dalej
      4. Nadal możemy łatwo nawigować po kodzie
  8. Modularyzacja aplikacji z kontenerem IoC
    1. Zarządzanie konfiguracją
    2. Każdy komponent jako moduł kontenera IoC - składamy aplikację jak z klocków
    3. Wykorzystanie w testach
  9. CQRS
    1. Uzasadnienie modelu do odczytu
    2. Implementacja
      1. Stos do zapisu (ang. write stack)
        1. Command + Command Handler
        2. Wpływ na hermetyzację komponentu
      2. Stos do odczytu (ang. read stack)
        1. różnica tylko na poziomie kodu
        2. różnica na poziomie zapisu danych (kilka tabel/kolekcji/indeksów etc)
        3. różnica na poziomie bazy danych (kilka baz danych)


Pobierz program w formacie PDF

Trenerzy

Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.

Materiały związane ze szkoleniem

Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.

Zamów szkolenie

Imię i nazwisko:
Firma:
E-mail:
Nr tel:
Temat:
Wiadomość:

Jeżeli preferujesz osobisty kontakt to zawsze możesz zadzwonić.

Iwona Sobótka

Koordynatorka szkoleń


Twoje dane osobowe przetwarzamy, aby udzielić odpowiedzi na Twoje pytanie. Administratorem Twoich danych osobowych jest Bottega It Minds Sławomir Sobótka. Przysługuje Ci prawo wniesienia sprzeciwu wobec przetwarzania, prawo dostępu do danych, prawo żądania ich sprostowania, usunięcia lub ograniczenia ich przetwarzania. Szczegółowe informacje dotyczące przetwarzania Twoich danych osobowych znajdują się TUTAJ.