Katalog architektur, DDD, mikroserwisy, czysta i cebulowa architektura a także kilka słów wprowadzających do tematu, w tym czym jest architektura, jej poziomy, rola w dokumentowaniu rozwiązań i problemy przy próbach egzekwowania.

1. Katalog Architektur
Tomasz Borek, @LAFK pl,

2. Agenda
Organizacyjne 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

3. ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

4. 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

5. Przebieżka po nowoczesnych (i nieco starszych) architekturach, celem ich
przybliżenia raczej niż zgłębienia.
Organizacyjne sprawy
Przerwy - jak chcecie
Tempo - jak chcecie
Pytania - też jak chcecie
O mnie
Dzisiaj
Nie dogłębnie ile raczej płytko o innych i znacznie rzadszych niż trójwarstwówka podejściach do
archi.
Chciałbym:
!
1

6. 
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

7. 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

8. !
a tzw. czerwoną?
!
O refaktoryzacji bazek?
4

9. !
O integracji w korpo-archi? Niezbędna w EE.
http://www.slideshare.net/melbournepatterns/enterprise-integration-patterns
5

10. !
Starszą acz dobrą o OO przez testy?
6

11. !
O µserwisach?
7

12. !
O architekturze dla programistów?
http://www.codingthearchitecture.com/
8

13. !
O dokumentowaniu archi? Po rozdziale trzecim…
9

14. !
http://www.viewpoints-and-perspectives.info/
10

15. Koncepty: udziałowców, perspektyw, widoków
Zagrajmy
Pierwsze 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

16. • Architektura korporacyjna (organizacji)
Architektura kodu
Poprzez definiowanie struktury, wzorce projektowe pomagają programiście
skupić się przede wszystkim na dziedzinie, na tym co system ma robić dla
użytkownika
Wzorce projektowe
Wzorce 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łen
trafnych 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 Principle
klasę można łatwo rozszerzać, nie modyfikując jej
• L iskov Substitution Principle
potomkowie to przeźroczyste zamienniki przodków
• I nterface Segregation Principle
dla różnych klientów twórz osobne interfejsy
• D ependency Inversion Principle
zależ od abstrakcji a nie od konkretnych implementacji
12

17. 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ę
• Prostota
wprowadzaj 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 razem
ponieważ zmieniają się w tym samym czasie
• Symetria
utrzymuj podobny poziom abstrakcji
Egzekwowanie "architektury"
• W jaki sposób egzekwować architekturę?
• Code Review? Architecture Review?
• SonarQube? Metrics?
• Automated test suites? Chaos Monkey?
Warstwy
13

18. 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

19. EA - definicja
Zbiór właściwości danej organizacji (korporacji) które stanowią o jej
moż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

20. 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

21. Architektura jako strategia?
1. Jak to robią w wojsku?
2. Jak, co i kiedy?
3. Dlaczego i gdzie?
!
!
17

22. 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

23. • 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 Design
1. Sposób myślenia, według którego tworzona jest architektura systemu
2. Wszechobecny (ubiquitous) język dziedzinowy, w którym porozumiewają się interesariusze i
programiści
3. Odwzorowywanie w kodzie bytów i procesów biznesowych zarówno pod względem zachowania
jak 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

24. 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

25. !
Bounded Context
Bounded contexts should have a name so that you can talk about them.
— Eric Evans
21

26. Kontekst
Bounded Context nie oznacza tylko enkapsulacji kodu lecz wyodrębnienie pewnego zagadnienia w
pł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

27. Przykłady
* Wysokopoziomowe API na urządzenia sieciowe
* Odizolowanie kodu napisanego w C od nowego kodu tworzonego w C++
!
23

28. 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 domenowy
1. Dostępny
2. Rozumie ograniczenia
3. Rozumiany
4. Limit systemu!
Co mówi język?
@DomainService
public 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 od
adresu klienta na zamówieniu
Skutki uboczne
Jako ż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ólnych
pozycji
24

29. !
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

30. !
26

31. Kluczowe klocki
• Entity – identyfikowalne obiekty zawierające odpowiedzialność biznesową
• Aggregate – hermetyczne grafy obiektów, z jedną encją będącą "korzeniem agregatu", która
stanowi 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 wygodny
interfejs
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

32. • 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

33. Mikroserwisy
µservices
• Monolith vs µServices
• Smart endpoints and dumb pipes
• Decentralize your data
• Automate infrastructure
29

34. Microservices are the new black
Monolithic vs Micro
Layers don’t matter anymore. Or, matter at much smaller scale.
!
Connections matter more though.
30

35. And how SOA fits?
So I get rid of complexity?
NO.
31

36. Monolithic TO micro then?
Tech and org transformational journey…
So! Microservices?
Micro Service is an architectural concept that aims to decouple a solution by
decomposing functionality into discrete services […] with communication over
lightweight 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

37. •
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 design
whose structure is a copy of the organization’s communication structure.
— Conway's Law, Melvyn Conway
33

38. 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 Fallacies
Keep 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

39. There’s an excellent PDF in the matter, called Fallacies of Distributed Computing.
Tooling matters
http://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 ID
1. Requestor → Request message (with assigned request ID
an identifier that is different from those for all other currently outstanding
requests, 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 that
ID to the reply as a correlation ID. When the requestor processes the reply, it
uses the correlation ID to know which request the reply is for. This is called a
Correlation Identifier because of the way the caller uses the identifier to
correlate each reply to the request that caused it.
— Enterprise Integration Patterns
35

40. Implications
1. 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 lub
jakiekolwiek zewnętrznego elementu
!
• Niezależność od interfejsu użytkownika
• Interfejs użytkownika musi być łatwo wymienialny bez wpływu na resztę systemu. WWW na
CLI, 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, SQL
Server, MongoDB czy Couchbase
Jak to wygląda?
36

41. 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

42. Typowe warstwy
38

43. Clean architecture
39

44. Onion Architecture
Analogiczne założenia jak przy clean architecture
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
40

45. 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 od
infrastruktury
Jak to wygląda?
41

46. Podsumowanie
Powtó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 architektura
Warstwowe podejście, uniemożliwiające wprowadzenie zewnętrznego kodu za głęboko w domenę.
Szybka możliwość podmiany komponentów.
42

47. Heksagon
Porty to wejścia do systemu, adaptery to kod przejścia.
43