Nowoczesne architektury

Katalog ArchitekturTomasz Borek, @LAFK pl,

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

!a tzw. czerwoną?

!O refaktoryzacji bazek?

4

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

5

http://www.slideshare.net/melbournepatterns/enterprise-integration-patterns

!Starszą acz dobrą o OO przez testy?

6

!O µserwisach?

7

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

8

http://www.codingthearchitecture.com/

!O dokumentowaniu archi? Po rozdziale trzecim…

9

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

10

http://www.viewpoints-and-perspectives.info/

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

http://www.joelonsoftware.com/articles/fog0000000018.html

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

http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions

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




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

!




Modelowanie z DDD

25

!

26

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

And how SOA fits?

So I get rid of complexity?NO.

31

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

http://www.slideshare.net/nathariel/moving-to-microservices-a-technology-and-organisation-transformational-journey

•

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

https://pages.cs.wisc.edu/~zuyu/files/fallacies.pdf

https://pages.cs.wisc.edu/~zuyu/files/fallacies.pdf

http://www.slideshare.net/MarcinGrzejszczak/microservices-enough-with-theory-lets-do-some-code-geecon-prague-2015

http://www.slideshare.net/MarcinGrzejszczak/microservices-enough-with-theory-lets-do-some-code-geecon-prague-2015

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

http://theburningmonk.com/2015/05/a-consistent-approach-to-track-correlation-ids-through-microservices/

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

Typowe warstwy

38

Clean architecture

39

Onion ArchitectureAnalogiczne założenia jak przy clean architecture

http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

40

http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

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

HeksagonPorty to wejścia do systemu, adaptery to kod przejścia.

43