Receptury - niezbędnik projektanta i architekta

Tytuł: Receptury - niezbędnik projektanta i architekta
Kod: Craft-Receptury
Kategoria: Wzorce i Craftsmanship
Forma: 50% wykłady / 50% warsztaty
Czas trwania: 3 dni
Odbiorcy: architekci, developerzy
Zapisy: Indywidualne zamówienie i dopasowanie dla grupy.
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.

Program szkolenia został zaprojektowany z myślą o typowych problemach projektowych i architektonicznych, które pojawiają się w niemal każdym systemie oraz sprawdzonych receptach na ich rozwiązanie.

Szkolenie prowadzone jest w podejściu zorientowanym na problem. Każdy moduł to opis problemu oraz alternatywnych sposobów jego rozwiązania wraz z omówieniem konsekwencji wynikających z danego podejścia.

Podejścia i techniki przedstawione podczas szkolenia są nieodzownym składnikiem "skrzynki z narzędziami" każdego projektanta i architekta.

Materiały wstępne

Przed szkoleniem możesz zapoznać się z serią naszych artykułów: Receptury projektowe – niezbędnik początkującego architekta.

Wyróżniki szkolenia

  • Typowe problemy i ich rozwiązania
  • Wykorzystanie sprawdzonych technik i wzorców
  • Realne przykłady

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. Zarządzanie złożonością modeli biznesowych
    1. Rozwarstwienie logiki w celu uporządkowania odpowiedzialności
      1. Logika Aplikacji - model Use Case/User Story
      2. Logika Domenowa - model reguł biznesowych
    2. 4 poziomy modelu w celu zarządzania zmianą logiki domenowej
      1. Decission Support - logika analityczna
      2. Policy - dostrojenie modelu
      3. Operations - model operacji
      4. Capability - model potencjału
    3. Podejście archetypów modeli biznesowych
      1. Knowledge Level - modele ulegające zmianie
      2. Operation Level - modele nieulegające zmianie
    4. Podział kodu na 3 grupy - Open Close Principle
      1. Logika Stała
        1. Wydzielenie logiki, która podlega relatywnie niewielu zmianom
      2. Rozbudowana
        1. Polityki
        2. Wzorzec Strategii
        3. Podejście funkcyjne
      3. Zmiana
        1. Fabryki - hermetyzacja reguł wyboru polityki/strategii/funkcji
        2. Parametryzacja przy pomocy kontenerów IoC
  2. Architektury aplikacji otwarte na rozbudowę
    1. Typowe problemy w kastomizowalnych systemach dostosowywanych per wdrożenie
    2. Alternatywa: podejście plugin-oriented
    3. Wykorzystanie kontenerów IoC
      1. Wstrzykiwanie zależności - pluginy typu "coś działa inaczej"
        1. Wstrzykujemy nie tylko DAO
        2. Zarządzenie odmiennością logiki
        3. Wstrzykiwanie Strategy Design Pattern
      2. Event Driven - pluginy typu "dodatkowa funkcjonalność"
        1. Listenery jako pluginy
        2. Listenery jako alternatywne klienty do API
    4. Extension Object Pattern
  3. Modularyzacja
    1. Projektowanie API modułu
    2. Hermetyzacja modułu w celu separacji zmian
    3. Podejście Bounded Context
      1. Granica modułu wyznaczana przez ograniczenia wiedzy
    4. Model kanoniczny
    5. Integracja modułów
      1. Podejścia SOA
      2. Podejście Event Driven
        1. Listenery jako alternatywne klienty do API
      3. Kiedy warto wprowadzić Data Transfer Object - a kiedy jest to zbędny narzut
    6. Architektura Heksagonalna (Ports and Adapters)
  4. Multitennancy
    1. Na poziomie bazy danych
      1. 3 podejścia
    2. Na poziomie logiki biznesowej
      1. polityki
    3. Na poziomie API
      1. Commmand + Handler
      2. Wersjonowanie handlerów
  5. DDD Lite - Building Blocks modelowanie złożonych domen
    1. Techniki Domain Driven Design - Building Blocks
    2. Agregaty
      1. Modelowanie niezmienników
      2. Modelowanie granicy Agregatu jako jednostki pracy
    3. Encje
    4. Value Objects
    5. Serwisy Domenowe
    6. Polityki
      1. Wykorzystanie Dependency Injection
    7. Specyfikacje
      1. Modelowanie złożonych kryteriów
    8. Fabryki
      1. Modelowanie złożonego procesu tworzenia obiektów
      2. Wartości początkowe, walidacja półproduktów, składanie obiektów, wstrzykiwanie zależności
    9. Repozytoria
      1. Abstrakcja źródła danych
  6. Testability - projektowanie kodu otwartego na testowanie
    1. Typowe błędy projektowe
      1. Eksplozja kombinatoryczna przypadków wynikająca z braku rozwarstwienia logiki
      2. Konieczność testowania przez UI wynikająca z nieprzestrzegania warstw
      3. Konieczność testowania z bazą danych wynikająca z braku separcji odpowiedzialności
    2. Techniki i taktyki
      1. Unikanie pracy z serwerem aplikacyjnym i bazodanowych
      2. Podejście funkcyjne - testowanie funkcji
        1. Projektowanie Serwisów Domenowych
        2. Projektowanie oparte o Strategy Design Pattern
      3. Hermetyzacja zależności w Fabrykach
    3. Modelowanie i testowanie niezmienników
    4. Projektowanie klas testowych
      1. Unikanie potrzeby tworzenia Mock/Stub/Fake
      2. Wprowadzanie Object Mother
      3. Wprowadzanie Assemblerów obiektów
      4. Wprowadzenie własnych Assert Object
  7. Modelowanie ról w systemie
    1. Wady podejścia opartego o dziedziczenie
    2. Role Object Pattern
      1. Role zapewniające funkcjonalność
    3. Party Archetype i Party Relationship Archetype
      1. Model uczestników relacji
      2. Integracja z Role Object Pattern
  8. Konglomeraty wzorców - struktury rozwiązań typowych problemów
    1. Fabryka Strategii - Separacja logiki stałej od zmiennej oraz zmiany od rozbudowy
      1. Zapewnienie Open Close Principle
      2. Fabryka Dekorowanych Strategii
      3. Fabryka Strategii Szablonowych
      4. Fabryka Strategii Łańuchowych
    2. Command operujący na Micro Kernel - Separacja logiki API od aplikacji
      1. Wsparcie dla operacji Undo
      2. Wsparcie dla podejścia Aspect Oriented Programming
    3. Visitor typów wyliczeniowych
      1. Unikanie instrukcji switch
      2. Wykrywanie nieobsłużonych wartości przez kompilator
      3. Zapewnienie kohezji typów wyliczeniowych
  9. Maszyny Stanów
    1. Typowe błędy w projektowaniu maszyn stanów
      1. Zbytnie uogólnienie
      2. Rzadkie macierze przejść
    2. Jak zaprojektować dobrą maszynę stanów
  10. Walidacja obiektów - rozwiązanie łatwe w rozbudowie i testowaniu
    1. Strategia Walidacji zwracająca listę błędów
    2. Implementacja strategii oparta o łańcuch kryteriów
    3. Parametryzowalne kryteria
    4. Łatwe testowanie poszczególnych kryteriów
  11. Złożone warunki logiczne w formie drzew decyzyjnych
    1. Specification Design Pattern
    2. Łatwe testowanie poszczególnych specyfikacji
    3. Fabrykowanie drzew per wdrożenie/sesja/użytkownik


Pobierz program w formacie PDF

Trenerzy

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

Szymon Janikowski

trener Java

Michał Michaluk

trener

Jakub Pilimon

trener

Grzegorz Piwowarek

trener Java

Chcieć to móc

Paweł Skiścim

Trener Agile, Software Craftsman

Łukasz Szydło

trener

Praktyka czyni mistrza

Bartłomiej Słota

Programista, konsultant, mentor i trener

Marcin Zajączkowski

trener java, craft, ci/cd

Działający kod to za mało.

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.