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