Mikroserwisy, Python i DDD - kompendium

Tytuł: Mikroserwisy, Python i DDD - kompendium
Kod: python-ddd5
Kategoria: Python
Forma: 40% wykłady, 60% warsztaty
Czas trwania: 5 dni
Odbiorcy: architekci, developerzy
Zapisy: Indywidualne zamówienie i dopasowanie dla grupy.
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.

Kompleksowe, 5-dniowe szkolenie z budowania rozproszonych systemów informatycznych w Pythonie w oparciu o Domain-driven design.

Szkolenie kładzie nacisk na zaprojektowanie modularności, a następnie integrowanie komponentów w niezawodny sposób.

Koncentrujemy się na rozwiązywaniu rozmaitych problemów związanych z komunikacją asynchroniczną oraz poznawanie wzorców wspomagających - jak Saga czy CQRS.

Ostatniego dnia zajmujemy się tematyką monitorowania z klasycznymi metrykami oraz Distributed Tracing. Uzupełnimy też wiadomości z testowania, zapewniając jakość w budowanym systemie.

  • Dzień 1: Wyznaczanie granic i projektowanie modularności
  • Dzień 2: Wzorce taktyczne DDD
  • Dzień 3: System rozproszone i architektura sterowana zdarzeniami
  • Dzień 4: Niezawodność w systemach rozproszonych
  • Dzień 5: Testowanie, monitorowanie i zapewnienie jakości

Wyróżniki szkolenia

  • Pragmatyczne podejście
  • Szukanie granic autonomicznych modułów
  • Sprawdzone wzorce architektoniczne

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. Event Storming - analizujemy system
    1. Zastosowania Event Stormingu
    2. Poziomy Event Stormingu
    3. Myślenie zdarzeniami
    4. Big Picture - pierwszy rzut oka na system z lotu ptaka
      1. Zdarzenie
    5. Process Level Event Storming - odkrywamy procesy i proponujemy Bounded Contexty
      1. Komenda
      2. Aktor
      3. Hotspot
  3. DDD i modularność w praktyce - szukamy Bounded Contextów
    1. Poddomeny - problem space
    2. Bounded Contexty - solution space
    3. Heurystyki znajdowania Bounded Contextów
    4. Budujemy mapę kontekstów
  4. Drivery architektoniczne
    1. Specyfika technologii
    2. Specyfika biznesowa
    3. Wymagania funkcjonalne
    4. Wymagania niefunkcjonalne
    5. Inne
  5. Inne heurystyki wspomagające projektowanie modularności
    1. Zgodność z regulacjami
    2. Security
    3. Częstość zmian
    4. Ryzyko
    5. Wydajność
    6. Model współbieżności
  6. Zapachy architektury świadczące o nieoptymalnym designie
    1. Cyclic dependency
    2. Feature / data envy
    3. God component
    4. Dense Structure
  7. Projektujemy system składający się z mikroserwisów
    1. Założenia
      1. Projektowanie z myślą o awariach
      2. Podejście ewolucyjne
      3. Decentralizacja zarządzania danymi
    2. Jak określić granicę serwisów
      1. Podejście Bounded Context z DDD
      2. Antywzorzec: Nanoservice
      3. Antywzorzec: Rozproszony CRUD
  8. Pułapki czyhające przy projektowaniu systemu rozproszonego
    1. Współdzielona baza danych
    2. Nadużywanie synchronicznej komunikacji
    3. Pojedynczy punkt awarii
    4. Źle wyznaczone granice
    5. Brak możliwości niezależnego wdrożenia
  9. Agregaty
    1. Heurystyki projektowania
      1. Gwarancja spójności reguł biznesowych
      2. Granica spójności transakcji
      3. Preferowanie małych agregatów
      4. Przechowywanie tożsamości innych agregatów
      5. Używanie eventual consistency do synchronizacji stanu agregatów
    2. Kiedy łamiemy zasady? Na co uważać?
    3. Walidowanie zaprojektowanych agregatów
      1. Upewnienie się, że problemy z początku szkolenia nam nie grożą
  10. Value objects
    1. Odpowiednie do modelowania konceptów
  11. Serwisy Domenowe
    1. Model procedur biznesowych
  12. Fabryki
    1. Walidacja
    2. Logika biznesowa podczas składania obiektów
    3. Wsparcie testowalności
  13. Polityki (strategie)
    1. Modelowanie w stylu funkcyjnym
    2. Open Close Principle (SOLID) w praktyce
  14. Zdarzenia dziedzinowe
    1. Wyzwalanie akcji w ramach tego samego Bounded Contextu
    2. Event Bus
    3. Integrowanie Bounded Contextów
  15. Czysta architektura / Porty i Adaptery
    1. Logika orkiestracji - Przypadek użycia / Serwis aplikacyjny
    2. Logika zmiany - encje oraz wzorce taktyczne z DDD
    3. Logika walidacji - specyfikacja, DTO
  16. Integrowanie Bounded Contextów
    1. Kierunek zależności
      1. Komendy
      2. Zdarzenia
    2. Anticorruption Layer
    3. Open Host / Published Language
    4. Customer - Supplier
    5. Shared Kernel
  17. Komunikacja synchroniczna - API
    1. REST API
      1. Podstawy projektowania API
      2. Model dojrzałości Richardsona
      3. Dokumentowanie na przykładzie OpenAPI
    2. Wady i pułapki komunikacji synchronicznej
      1. Zwiększanie podatności na awarie
      2. Temporal coupling
  18. Komunikacja asynchroniczna - Wiadomości
    1. Asynchroniczne komendy
    2. Zdarzenia
  19. CQRS
    1. Ogólne założenia
      1. Wertykalny podział
      2. Model zapisu
      3. Model odczytu
    2. Przykładowe zastosowania
      1. widok dla panelu administracyjnego
      2. raportowanie
      3. audit log
    3. Read model tylko na poziomie kodu
    4. Budowanie read modeli - synchronicznie
    5. Budowanie read modeli - asynchronicznie
    6. Radzenie sobie z opóźnieniem odświeżenia read modelu
  20. Wzorce Sagi i Process Managera
    1. Orkiestracja kontra choreografia w architekturach sterowanych zdarzeniami
    2. Stanowy Process Manager czy bezstanowa Saga?
    3. Zarządzanie długim procesem
    4. Kompensacja
    5. Obsługa timeoutów
  21. Gwarancje dostarczenia
    1. Najczęściej uzyskiwana - at-most-once
    2. Najczęściej potrzebna - at-least-once
    3. Najczęściej pożądana - exactly-once
    4. Wybór właściwej gwarancji
  22. Outbox Pattern
    1. Pułapka wysłania za wcześnie - przed zatwierdzeniem transakcji
    2. Pułapka wysłania później - po zatwierdzeniu transakcji
    3. Gwarancja wysłania wiadomości
    4. Implementacja z relacyjną bazą danych
    5. Skalowanie z relacyjną bazą danych
  23. Radzenie sobie z nieprawidłowymi wiadomościami
    1. Walidacja
    2. Odrzucanie
    3. Kolejka na nieprawidłowe wiadomości
  24. Dead Letter i finalizacja wiadomości
    1. realizacja na wybranym brokerze
    2. ponowne próby
      1. backoff
      2. ilość maksymalna
    3. polityka finalizacji i retencji nieskonsumowanych wiadomości
  25. Wzorzec Idempotent Receiver i deduplikacja wiadomości
    1. Ignorowanie duplikatów
    2. Ponowne przetworzenie tych samych wiadmości
    3. Strategie deduplikacji
      1. Identyfikator wiadomości
      2. Wersja
      3. Idempotentna wiadomość
  26. Ewolucja i wersjonowanie zdarzeń
    1. Potrzeba wersjonowania
    2. Serializacja wspierające ewolucję - Apache Avro, Protobuf, JSON Schema
    3. Przykład implementacji Schema Registry
    4. Jak wdrażać serwisy, by bezpiecznie migrować do nowszych wersji?
  27. Testowanie
    1. Testowanie akceptacyjne serwisu / komponentu
    2. Testy end-to-end
    3. Testy kontraktowe
      1. Consumer-driven Contract Testing
    4. Rodzaje test doubles i ich wpływ na test
      1. Mock
      2. Stub
      3. Dummy
      4. Fake
    5. Wzorce wspomagające
      1. Fabryki
      2. Warstwy w testach, DSL
    6. Testy syntetyczne
  28. Metryki
    1. Prometheus i Grafana
    2. Wsparcie w popularnych bibliotekach
    3. Budowanie własnych metryk
    4. Co warto mierzyć? Co dostajemy za darmo?
  29. Distributed Tracing
    1. opentelemetry
      1. Biblioteki
      2. Wsparcie
      3. Własna instrumentacja
        1. Dodawanie własnych danych do trace’ów
    2. Wizualizacja przepływów w systemie
    3. Znajdowanie źródła problemu wydajnościowego


Pobierz program w formacie PDF

Trenerzy

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

Sebastian Buczyński

Trener, lider techniczny, architekt

In theory, there is no difference between theory and practice. In practice, there is. (Yogi Berra)

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.