Receptury - niezbędnik projektanta i architekta

Kod: Craft-Receptury
Kategoria: Wzorce i Craftsmanship
Forma: 50% wykłady / 50% warsztaty
Czas trwania: 3 dni
Grupa docelowa: architekci
developerzy
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.
Data i dokładny zakres do ustalenia podczas analizy przed-szkoleniowej.

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

Podczas zajęć możesz oczekiwać szczególnych akcentów położonych na poniższe aspekty:

  • 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
      1. Unikanie tworzenia branch w repozytorium kodu
      2. Unikania wprowadzania logiki warunkowej
    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. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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.

Materiały związane ze szkoleniem

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

Zapytaj o 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ń