nowoczesne architektury
TRANSCRIPT
AgendaOrganizacyjne sprawy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
O mnie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Dzisiaj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Pytania? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Sprawdźmy poziom! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Łapki w górę kto… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Zagrajmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Pięć poziomów architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Architektura kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Wzorce projektowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Clean code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SOLIDny programista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Wartości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Implementation patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Implementation patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Egzekwowanie "architektury" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Warstwy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
EA - definicja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
EA - frameworki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Pojmowanie architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Problemy z projektowaniem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Architektura jako strategia? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Architektura jako strategia? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Dokumentowanie decyzji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Spis treści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Po co DDD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Domain Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Co to jest domena. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Izolacja domeny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Kiedy stosować? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Kontekst jest zawsze królem! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Bounded Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Kontekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Relacje między kontekstami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Rodzaje relacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Anti-corruption Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Spis treści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Ekspert domenowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Co mówi język?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Co mówi model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Skutki uboczne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Spis treści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Modelowanie z DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Kluczowe klocki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Przykłady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Value Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Agregat i niezmienniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Mikroserwisy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
µservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Microservices are the new black . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Monolithic vs Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
And how SOA fits? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
So I get rid of complexity? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Monolithic TO micro then? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
So! Microservices? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Summing up? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Organization matters!. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Cross-functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
When not to use? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Distributed Programming Fallacies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Tooling matters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Traceable requests? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Request ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Correlation ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
How to? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Clean + Onion architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Założenia clean architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Jak to wygląda? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Elementy architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Adaptery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
High level view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Typowe warstwy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Clean architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Onion Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Założenia Onion Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Jak to wygląda? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
DDD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
µserwisy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Cebula i czysta architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Heksagon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Przebieżka po nowoczesnych (i nieco starszych) architekturach, celem ichprzybliżenia raczej niż zgłębienia.
Organizacyjne sprawyPrzerwy - jak chcecieTempo - jak chceciePytania - też jak chcecie
O mnie
DzisiajNie dogłębnie ile raczej płytko o innych i znacznie rzadszych niż trójwarstwówka podejściach doarchi.
Chciałbym:
!
1
Przybliżyć Wam DDD
1. powiedzieć o wszechobecnym języku
2. o podstawowych klockach tego podejścia
3. o wzorcach w budowie tego
4. wyjaśnić czemu to moje ulubione podejście
!
Ostrzec Was przed modą, obecnie na µserwisy (wcześniej na SOA)
1. powiedzieć co to to SOA
2. i µserwis
3. przybliżyć zalety
4. pokazać wady, które nagminnie się pomija
!
Przypomnieć starsze, lecz ciekawe koncepty
1. Czystej architektury Wujka Boba
2. Cebuli
3. Portów i adapterów, tudzież heksagonu
Pytania?
2
Sprawdźmy poziom!
Łapki w górę kto…1. potrafi rozwinąć SOLIDa?
2. a GRASPa?
3. potrafi wymienić inne niż z programu znane podejścia?
4. potrafi opowiedzieć o podejściach z programu?
5. przeczytał książki:
!tzw. niebieską?
3
!O integracji w korpo-archi? Niezbędna w EE.http://www.slideshare.net/melbournepatterns/enterprise-integration-patterns
5
!O architekturze dla programistów?http://www.codingthearchitecture.com/
8
Koncepty: udziałowców, perspektyw, widoków
ZagrajmyPierwsze skojarzenie z architekturą?
Krzyczcie!
Wprowadzenie
Pięć poziomów architektury• Architektura kodu (klasy)
• Architektura aplikacji (komponenty)
• Architektura systemu (rozwiązania - kontenery)
• Architektura wdrożenia (infra)
11
• Architektura korporacyjna (organizacji)
Architektura kodu
Poprzez definiowanie struktury, wzorce projektowe pomagają programiścieskupić się przede wszystkim na dziedzinie, na tym co system ma robić dlaużytkownika
Wzorce projektoweWzorce odnoszą się do
• Odpowiedzialności - pojedyncza
• Hermetyzacji - dokładamy a nie modyfikujemy
• Inwazyjności zmian
Clean code
Czysty kod jest prosty i bezpośredni. Czysty kod czyta się jak dobrze napisanąprozę. Czysty kod nigdy nie zaciemnia zamiarów projektanta; jest pełentrafnych abstrakcji i prostych ścieżek sterowania
— Grady Booch - Software Archeologist - IBM
SOLIDny programista• S ingle Responsibility Principle
klasa powinna mieć tylko jeden powód do zmiany
• O pen Closed Principleklasę można łatwo rozszerzać, nie modyfikując jej
• L iskov Substitution Principlepotomkowie to przeźroczyste zamienniki przodków
• I nterface Segregation Principledla różnych klientów twórz osobne interfejsy
• D ependency Inversion Principlezależ od abstrakcji a nie od konkretnych implementacji
12
Wartości• Kod jest podstawowym medium komunikacji w projekcie
• Jako zespół jesteśmy jednością
• Programy są częściej czytane niż pisane
• Więcej czasu poświęcamy na modyfikację istniejącego kodu niż na tworzenie nowego
Implementation patterns• Komunikacja
kod źródłowy powinno się czytać jak książkę
• Prostotawprowadzaj złożoność tylko kiedy jest to konieczne
• Elastycznośćto dodatkowa złożoność, więc wprowadzaj ją tylko tam gdzie to konieczne
Implementation patterns• Lokalne konsekwencje
zmiana w jednym miejscu nie powoduje zmian w innych
• Dane i logika razemponieważ zmieniają się w tym samym czasie
• Symetriautrzymuj podobny poziom abstrakcji
Egzekwowanie "architektury"• W jaki sposób egzekwować architekturę?
• Code Review? Architecture Review?
• SonarQube? Metrics?
• Automated test suites? Chaos Monkey?
Warstwy
13
4+1• Nie ma pojedynczego spojrzenia na aplikację
• Każda aplikacja (system) ma kilku interesariuszy i każdy patrzy na system w inny sposób
• Użytkownicy
• Programiści
• Project Managerowie
• Inne widoki (views) są używane do przedstawienia innych perspektyw na system (viewpoints)
4+1
14
EA - definicja
Zbiór właściwości danej organizacji (korporacji) które stanowią o jejmożliwości realizacji celów
— własna parafraza Wikipedii
EA - frameworki• TOGAF - The Open Group Architecture Framework
• ArchiMate
Pojmowanie architektury• "Architektura" starzeje się bardzo szybko
• "Odcinamy się" w złym momencie
• Too much design in the architecture
• Architektura - wyznacza kierunek
• Projekt - szczegóły opisu
• Czy to właśnie nie doprowadziło nas do wielu problemów
• Astronauts' Architecture - artykuł Joel Spolsky
15
Problemy z projektowaniem• Opis architektury starzeje się
• Nie nadąża za kodem, staje się bezużyteczny
• Ma niewiele wspólnego z rzeczywistością
• Jak dużo (mało) architektury powinno być architekturze
• Bardzo łatwo jest wszystko nazwać "architekturą"
• Przypadki użycia, sekwencje, WSDLe itd
!
16
Architektura jako strategia?1. Jak to robią w wojsku?
2. Jak, co i kiedy?
3. Dlaczego i gdzie?
!
!
17
Architektura jako strategia?• Architektura powinna nam pomóc powiedzieć…
• Gdzie wprowadzić zmiany
• Dlaczego wprowadzić zmiany
• Wszystko inne jest projektem
• Jak implementować?
• Co zmieniać i kiedy?
Dokumentowanie decyzji• Architektura to historia podjętych (albo nie) decyzji
• Decyzje mają:
• Tytuł
18
• Kontekst
• Decyzję
• Status (zaakceptowana, odrzucona)
• Konsekwencje
Michael Nygard - Documenting Architecture Decisions
DDD
Spis treści• Po co Domain Driven Design?
• Ubiquitous language – komunikacja między programistami i ekspertami dziedzinowymi
• Bloki budujące w DDD i ich odpowiedzialności
Po co DDD?• Dla większość projektów, najważniejsze jest zrozumienie logiku działania biznesu (domeny, logiki
domeny)
• Działania i operacje w domenie powinny być oparte o dobrze zdefiniowany model
Domain Driven Design1. Sposób myślenia, według którego tworzona jest architektura systemu
2. Wszechobecny (ubiquitous) język dziedzinowy, w którym porozumiewają się interesariusze iprogramiści
3. Odwzorowywanie w kodzie bytów i procesów biznesowych zarówno pod względem zachowaniajak i zachowania
4. Zestaw konceptów i procedur podstępowania do tego
Co to jest domena• Domena to spójny podzbiór rzeczywistości biznesowej wraz obowiązującymi tam zasadami,
któremu można przypisać nazwę oraz jednoznaczną odpowiedzialność
• Finanse, kontroling
• Sterowanie ruchem sieciowym
• Domena wyłania się naturalnie, gdy trudno nam ogarnąć to, co robimy i trzeba spojrzeć na
19
problem z szerszej perspektywy
Izolacja domeny• Domena przekłada się na spójną jednostkę oprogramowania
• Współpracujące domeny powinny być od siebie odizolowane za pomocą interfejsów
• Bounded contexts! (później)
Kiedy stosować?• Domena jest złożona (nie wszystkie domeny mają charakter obiektowy)
• Zespół jest doświadczony w projektowaniu obiektowym
• Eksperci domenowi są stale dostępni
• Proces wytwarzania oprogramowania jest iteracyjny
Kontekst jest zawsze królem!
20
!
Bounded Context
Bounded contexts should have a name so that you can talk about them.
— Eric Evans
21
KontekstBounded Context nie oznacza tylko enkapsulacji kodu lecz wyodrębnienie pewnego zagadnienia wpłaszczyznach:
• Architektonicznej
• Organizacyjnej
• Słownikowej
• Mentalnej
Relacje między kontekstami• Wyodrębnienie kontekstów pozwala dostrzec relację między nimi
• Poszczególne relacje dają wskazówki dotyczące organizacji pracy nad systemem
Rodzaje relacji• Continuous Integration
• Shared Kernel
• Customer / Supplier
• Conformist
• Anti-corruption Layer
• Separate Ways
• Open Host Service
Anti-corruption Layer• Model chroniony jest warstwą abstrakcji, która amortyzuje zewnętrzne zmiany
• Kiedy stosować?
• System korzysta z kodu legacy
• System współpracuje z innymi systemami
!
22
Przykłady* Wysokopoziomowe API na urządzenia sieciowe* Odizolowanie kodu napisanego w C od nowego kodu tworzonego w C++
!
23
Spis treści• Po co Domain Driven Design?
• Ubiquitous language – komunikacja między programistami i ekspertami dziedzinowymi
• Bloki budujące w DDD i ich odpowiedzialności
Ekspert domenowy1. Dostępny
2. Rozumie ograniczenia
3. Rozumiany
4. Limit systemu!
Co mówi język?
@DomainServicepublic class BookKeeper { public Invoice issue(Order order, TaxPolicy taxPolicy) { //... }}
Co mówi model?• fakturę wystawiamy na podstawie całego zamówienia
• nie ma możliwości wystawienia faktury na poszczególne pozycje
• nie ma możliwości wystawienia faktury zbiorczej na kilka zamówień
• możemy obliczać podatki dla dowolnego kraju, jest to domknięcie operacji issue, niezależne odadresu klienta na zamówieniu
Skutki uboczneJako że model jest dokładnie oddany w kodzie, system działa tak jak rozumie to Ekspert Domenowy
• Ekspert rozumienie złożoności i kosztu zmian
• Cały zespół świadomie zaciąga dług techniczny i ogranicza punkty swobody modelu
• W powyższym przykładzie: nie możemy fakturować kilku zamówień ani poszczególnychpozycji
24
!
Spis treści• Po co Domain Driven Design?
• Ubiquitous language – komunikacja między programistami i ekspertami dziedzinowymi
• Bloki budujące w DDD i ich odpowiedzialności
Modelowanie z DDD
25
Kluczowe klocki• Entity – identyfikowalne obiekty zawierające odpowiedzialność biznesową
• Aggregate – hermetyczne grafy obiektów, z jedną encją będącą "korzeniem agregatu", którastanowi API całości. Agregat jest główną jednostką logiki domenowej w DDD
• Value Object – wrapper dla typów prostych, nadający im znaczenie biznesowe oraz wygodnyinterfejs
Przykłady• System ewidencji ludności – obiekt Adres jest encją, gdyż musi być unikatowy
• Wypożyczalnia książek – obiekt Adres nie jest encją, gdyż jest jedynie składową UżytkownikaBiblioteki
27
• Student w kontekście finanse to zaledwie imię, nazwisko, nr albumu i konta.
• Student w ewidencji studentów to także listy przedmiotów i ocen (dużo kolumn i pól).
Value Object• Grupuje dane należące do pewnej całości
• Nietrwały, nieunikatowy
• NumerTelefonu, KodPocztowy
• Pozwala nazwać konkretny byt z domeny
• Implementowany w oparciu o wzorzec Immutable
• Często używany w parametrach metod
Agregat i niezmienniki• Zdania opisujące prawidłowości i reguły systemu
• Nie można dwa razy X
• Po każdej modyfikacji zawsze Y
• Jeżeli A wzrasta, to B maleje
!
28
Mikroserwisy
µservices• Monolith vs µServices
• Smart endpoints and dumb pipes
• Decentralize your data
• Automate infrastructure
29
Microservices are the new black
Monolithic vs MicroLayers don’t matter anymore. Or, matter at much smaller scale.
!Connections matter more though.
30
Monolithic TO micro then?Tech and org transformational journey…
So! Microservices?
Micro Service is an architectural concept that aims to decouple a solution bydecomposing functionality into discrete services […] with communication overlightweight mechanisms, often an HTTP resource API.
— Nick Nance and Jacob Madden
Summing up?• Small business problem
• Independent and so deployed
• It’s own process
32
•
Integrates explicite through common interfaces
• While HTTP isn’t always the best answer, it’s a damn fine first guess
• Owns it’s data
Organization matters!1. Conway’s law - you produce software organized as your company is
2. µservice won’t happen if you need to wait on shared teams (UX or - especially! - OPS)
!
!
Any organization that designs a system (defined broadly) will produce a designwhose structure is a copy of the organization’s communication structure.
— Conway's Law, Melvyn Conway
33
Cross-functional
When not to use?1. Not good enough infra
2. No DevOps (or folks willing to become DevOps by baptism of fire)
3. Organizational constraints
4. Devs not aware of infra realities / distributed programming fallacies
Distributed Programming FallaciesKeep in mind, that often programmers code, as if:
1. network was infallible
2. latency was zero
3. bandwith was infinite
4. and so on
!Which obviously isn’t the case. Network and cabling are done by humans and thus flawed. They break.
34
There’s an excellent PDF in the matter, called Fallacies of Distributed Computing.
Tooling mattershttp://www.slideshare.net/MarcinGrzejszczak/microservices-enough-with-theory-lets-do-some-code-geecon-prague-2015
Note how many tools they have on the setup diagram.Note how many they used and NOT mentioned on that diagram (second to last slide lists them all).
There are many tools involved and infrastructure cannot be neglected.
Traceable requests?1. message-driven apps, asynchronous calls
2. plethora of services, how users go about the system?
3. Correlation ID helps in finding out
4. Correlate i.e. match; show the relationship
Request ID1. Requestor → Request message (with assigned request ID
an identifier that is different from those for all other currently outstandingrequests, that is, requests that do not yet have replies.
— Enterprise Integration Patterns
Correlation ID
When the replier processes the request, it saves the request ID and adds thatID to the reply as a correlation ID. When the requestor processes the reply, ituses the correlation ID to know which request the reply is for. This is called aCorrelation Identifier because of the way the caller uses the identifier tocorrelate each reply to the request that caused it.
— Enterprise Integration Patterns
35
Implications1. Correlation id should be an element of Shared Components API
2. User’s request flow
3. Must be reproducible based on log files and the correlation id
How to?Yan Cui explains it nicely!
Clean + Onion architecture
Założenia clean architecture• Niezależność od frameworka
• architektura nie może zależeć od obecności (lub nie) któregoś frameworka. Biblioteki sąnarzędziami a nie elementem rozwiązania
• Testowalność
• Reguły biznesowe muszą być testowalne bez UI, bazy danych, serwera aplikacyjnego lubjakiekolwiek zewnętrznego elementu
!• Niezależność od interfejsu użytkownika
• Interfejs użytkownika musi być łatwo wymienialny bez wpływu na resztę systemu. WWW naCLI, bez wpływu na reguły biznesowe
• Niezależność od bazy danych
• Reguły biznesowe nie mogą być zależne od konkretnego silnika bazy danych: Oracla, SQLServer, MongoDB czy Couchbase
Jak to wygląda?
36
Elementy architektury• Encje
• Przypadki użycia
• Adaptery
• Frameworks and Drivers
Adaptery• Warstwa pośrednia między sednem aplikacji i satelitami (jak UI czy BD)
• Transformują dane z formatu odpowiedniego dla przypadków użycia i encji na język bazy danych,WWW.
• Co jest przekazywane do sedna aplikacji nie powinno zawierać elementów świata zewnętrznego
• SQL, ResultSet, MongoDB Collection, BSON, HttpSession, HttpRequest
High level view
37
Onion ArchitectureAnalogiczne założenia jak przy clean architecture
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
40
Założenia Onion Architecture• Aplikacja zbudowana jest dookoła niezależnego (od frameworku) modelu obiektowego
• Wewnętrzne warstwy definiują interfejsy, które zewnętrzne warstwy implementują
• Sprzęgnięcia są od zewnątrz do środka
• Zewnętrzne warstwy zależą od wewnętrznych, a nie odwrotnie
• Kod aplikacji (application core) może być kompilowany i uruchamiany niezależnie odinfrastruktury
Jak to wygląda?
41
PodsumowaniePowtórzmy ciekawe rzeczy.
1. architektura jest czym innym dla każdego z nas
2. wiele sposobów na ujęcie jej w projekcie / systemie
DDD?DDD stawia na eksperta domenowego, wszechobecny język i izolację domen (konteksty)
µserwisy?Samodzielne małe programiki z dobrą inter-komunikacją i zautomatyzowaną infrastrukturą
Cebula i czysta architekturaWarstwowe podejście, uniemożliwiające wprowadzenie zewnętrznego kodu za głęboko w domenę.Szybka możliwość podmiany komponentów.
42