Podstawy architektury
oprogramowania dla inżynierów
Rola
architekta oprogramowania się zmienia. Dziś jest on odpowiedzialny za
wiele spraw, zarówno technicznych, jak i tych wynikających
ze specyfiki organizacji, której ma służyć aplikacja. Co
więcej, rola architekta nie kończy się na podjęciu decyzji projektowych
na początku pracy. Nowoczesne style architektoniczne, takie jak
mikrousługi, umożliwiają przyrostowe wprowadzanie zmian, co jednak
wymusza ciągłe wypracowywanie kompromisów z innymi
kwestiami. Obszar architektury wciąż się zmienia i wymaga podejmowania
decyzji. Mało tego, architekt musi bezustannie analizować i
aktualizować podstawy, które bierze pod uwagę przy tych
decyzjach. Ważne są kontekst, perspektywy i wciąż zmieniający się
ekosystem dostępnych technologii.
Oto
kompleksowy przewodnik po nowych aspektach architektury oprogramowania.
Skorzysta z niego zarówno praktykujący architekt, chcący
odświeżyć swoje podejście do tego zagadnienia, jak i programista
aspirujący do roli architekta. W książce zaprezentowano szereg
zagadnień, które mimo zmieniających się uwarunkowań
pozostają podstawami, takich jak parametry architektury, wzorce
architektoniczne, określanie składników, tworzenie
diagramów, prezentowanie architektury, architektura
ewolucyjna i wiele innych. Dokładnie wyjaśniono te zasady,
które mogą być zastosowane do wszystkich zestawów
rozwiązań technologicznych. Przedstawiono niezwykle ważną kwestię
analizy kompromisów, która pozwala na obiektywną
ocenę rozwiązań technologicznych. Duży nacisk położono na konieczność
uwzględniania wszystkich innowacji ostatniej dekady.
Najciekawsze zagadnienia:
- wzorce architektoniczne
- etapy pracy przy
projektowaniu nowoczesnej architektury
- umiejętności miękkie
pomocne w pracy architekta
- nowe praktyki w
projektowaniu architektury oprogramowania
- architektura
oprogramowania jako dziedzina inżynierii
Przedmowa:
obalanie aksjomatów 13
1.
Wprowadzenie
17
Zdefiniowanie architektury oprogramowania 19
Oczekiwania wobec architekta 22
Podejmowanie decyzji architektonicznych 23
Ciągłe analizowanie architektury 23
Śledzenie najnowszych trendów 24
Zapewnienie zgodności z decyzjami 24
Bogate i zróżnicowane doświadczenie 25
Wiedza z zakresu biznesu 25
Umiejętności interpersonalne 26
Znajomość i umiejętność stosowania polityki firmy 26
Punkty przecięcia architektury z innymi elementami 27
Praktyki inżynieryjne 28
Operacje (DevOps) 31
Proces 32
Dane 32
Prawa architektury oprogramowania 33
CZĘŚĆ I.
PODSTAWY
2.
Myślenie architektoniczne 37
Architektura a projekt 38
Rozpiętość techniczna 39
Analiza kompromisów 43
Czynniki biznesowe 46
Zachowanie równowagi między architekturą a kodowaniem 47
3.
Modułowość 49
Definicja 50
Pomiar modułowości 52
Spójność 52
Sprzężenie 55
Abstrakcyjność i niestabilność 56
Odległość od ciągu głównego 57
Splątanie 59
Unifikacja wskaźników sprzężenia i splątania 63
Od modułów do składników 64
4.
Definiowanie
parametrów architektury
65
(Niepełna) lista parametrów architektury 68
Operacyjne parametry architektury 68
Strukturalne parametry architektury 69
Przekrojowe parametry architektury 69
Kompromisy i najmniej niekorzystna architektura 73
5.
Identyfikacja
parametrów architektury
75
Określanie parametrów architektury na podstawie zagadnień
dziedzinowych 75
Określanie parametrów architektury na podstawie wymagań 77
Studium przypadku: Krzemowe Kanapki 79
Parametry sprecyzowane 79
Parametry dorozumiane 83
6.
Pomiar
parametrów architektury i zarządzanie nimi 85
Pomiar parametrów architektury 85
Pomiary operacyjne 86
Pomiary strukturalne 87
Pomiary procesowe 89
Funkcje zarządzania i dopasowania 89
Zarządzanie parametrami architektury 89
Funkcje dopasowania 90
7.
Zakres parametrów architektury 97
Sprzężenie i splątanie 97
Kwanty architektury i ziarnistość 98
Studium przypadku: "Po raz pierwszy, po raz drugi, sprzedane!" 100
8.
Myślenie w oparciu o składniki 105
Zakres składnika 105
Rola architekta 106
Podział architektury 107
Studium przypadku: Krzemowe Kanapki - podział 110
Rola programisty 112
Proces identyfikacji składników 113
Identyfikacja składników początkowych 113
Przypisywanie wymagań do składników 113
Analiza ról i odpowiedzialności 114
Analiza parametrów architektury 114
Restrukturyzacja składników 114
Szczegółowość składników 114
Projektowanie składników 114
Odkrywanie składników 115
Studium przypadku: "Po raz pierwszy, po raz drugi, sprzedane!" -
odkrywanie składników 117
Jeszcze raz o kwantach architektury: wybór między
architekturą monolityczną a rozproszoną 120
CZĘŚĆ II.
STYLE ARCHITEKTONICZNE
9.
Podstawy
123
Podstawowe wzorce 123
Bryła błotna 123
Architektura unitarna 125
Klient-serwer 125
Architektury monolityczne a rozproszone 127
Mit 1. Sieć jest niezawodna 127
Mit 2. Opóźnienie jest zerowe 128
Mit 3. Przepustowość jest nieskończona 129
Mit 4. Sieć jest bezpieczna 130
Mit 5. Topologia nigdy się nie zmienia 131
Mit 6. Jest tylko jeden administrator 131
Mit 7. Koszt transportu jest zerowy 132
Mit 8. Sieć jest homogeniczna 133
Inne kwestie związane z rozproszeniem 133
10.
Styl
architektury warstwowej 135
Topologia 135
Warstwy izolacji 137
Dodawanie warstw 138
Inne kwestie 139
Dlaczego warto stosować ten styl architektoniczny? 140
Ocena parametrów architektury 141
11.
Styl
architektury potokowej 143
Topologia 143
Potoki 144
Filtry 144
Przykład 145
Ocena parametrów architektury 146
12.
Styl architektury mikrojądra
149
Topologia 149
Podstawowy system 150
Dołączane składniki 151
Rejestr 155
Kontrakty 156
Przykłady i przypadki użycia 156
Ocena parametrów architektury 157
13.
Styl
architektury bazującej na usługach 161
Topologia 161
Warianty topologii 162
Projektowanie usług i ich szczegółowość 164
Podział bazy danych 166
Przykład architektury 168
Ocena parametrów architektury 169
Kiedy należy używać tego stylu architektonicznego? 172
14.
Styl
architektury sterowanej zdarzeniami 173
Topologia 174
Topologia brokera 174
Topologia mediatora 179
Komunikacja asynchroniczna 186
Obsługa błędów 188
Zapobieganie utracie danych 191
Rozgłaszanie 193
Żądanie-odpowiedź 193
Wybór między modelem opartym na żądaniach a modelem opartym
na zdarzeniach 196
Architektury hybrydowe sterowane zdarzeniami 196
Ocena parametrów architektury 197
15.
Styl architektury przestrzennej 201
Ogólna topologia 202
Jednostka przetwarzająca 203
Zwirtualizowane oprogramowanie pośredniczące 203
Pompy danych 208
Jednostki zapisu danych 210
Jednostki odczytu danych 211
Kolizje danych 212
Wdrożenia chmurowe a lokalne 215
Buforowanie replikowane a rozproszone 215
Model near-cache 218
Przykłady wdrożeń 219
System sprzedaży biletów na koncerty 220
System aukcji internetowych 220
Ocena parametrów architektury 221
16.
Architektura
zorientowana na usługi sterowana orkiestracją
223
Historia i filozofia 223
Topologia 224
Taksonomia 224
Usługi biznesowe 224
Usługi korporacyjne 225
Usługi aplikacji 225
Usługi infrastrukturalne 225
Silnik orkiestracji 225
Przepływ komunikatów 226
Wykorzystuj ponownie... i sprzęgaj 227
Ocena parametrów architektury 229
17.
Architektura
mikrousług 231
Historia 231
Topologia 232
Rozproszenie 233
Ograniczony kontekst 233
Poziom szczegółowości 234
Izolacja danych 234
Warstwa API 235
Wieloużywalność operacyjna 235
Interfejsy 238
Komunikacja 239
Choreografia i orkiestracja 241
Transakcje i sagi 243
Ocena parametrów architektury 247
Dodatkowe informacje 248
18.
Wybór odpowiedniego stylu architektonicznego
249
Zmiana "mody" w architekturze 249
Kryteria decyzyjne 250
Studium przypadku architektury monolitycznej: Krzemowe Kanapki 253
Monolit modułowy 253
Mikrojądro 254
Studium przypadku architektury rozproszonej: "Po raz pierwszy, po raz
drugi, sprzedane!" 255
CZĘŚĆ III.
TECHNIKI I UMIEJĘTNOŚCI
MIĘKKIE
19.
Decyzje
architektoniczne 261
Antywzorce w decyzjach architektonicznych 261
Antywzorzec Obrona Swojego Stanowiska 261
Antywzorzec Dzień Świstaka 262
Antywzorzec Architektura Sterowana Wiadomościami E-mail 263
Istotność architektoniczna 264
Rejestr decyzji architektonicznych 264
Podstawowa struktura 265
Przechowywanie dokumentów ADR 270
ADR jako dokumentacja 272
Wykorzystanie dokumentów ADR do standaryzacji 272
Przykład 273
20.
Analiza
ryzyka w architekturze 275
Macierz ryzyka 275
Ocena ryzyka 276
Risk storming 279
Identyfikacja 281
Konsensus 281
Ograniczanie 283
Analizy ryzyka historyjek w metodykach zwinnych 285
Przykłady risk stormingu 285
Dostępność 286
Elastyczność 288
Bezpieczeństwo 289
21.
Tworzenie
diagramów i prezentacja architektury
293
Diagramy 294
Narzędzia 294
Standardy tworzenia diagramów: UML, C4 i ArchiMate 296
Wskazówki dotyczące sporządzania diagramów 297
Prezentacja 298
Manipulowanie czasem 299
Diagramy przyrostowe 299
Karty informacyjne a prezentacje 300
Slajdy to połowa przekazu 302
Niewidoczność 302
22.
Zwiększanie
efektywności zespołów 303
Granice zespołów 303
Osobowości architektów 304
Maniak kontroli 304
Architekt fotelowy 306
Skuteczny architekt 307
Poziom kontroli 308
Znaki ostrzegawcze w zespole 312
Wykorzystanie list kontrolnych 315
Lista kontrolna gotowości kodu 317
Lista kontrolna testów jednostkowych i funkcjonalnych 318
Lista kontrolna wydania oprogramowania 318
Udzielanie wskazówek 319
Podsumowanie 321
23.
Umiejętności
negocjacyjne i zdolności przywódcze
323
Negocjacje i facylitacja 323
Negocjacje z interesariuszami biznesowymi 324
Negocjacje z innymi architektami 326
Negocjacje z programistami 327
Architekt oprogramowania jako lider 328
Cztery aspekty architektury 328
Bądź pragmatyczny, ale zarazem wizjonerski 330
Przewodzenie zespołom poprzez dawanie przykładu 331
Integracja z zespołem 335
Podsumowanie 338
24.
Rozwijanie ścieżki kariery zawodowej
339
Zasada 20 minut 339
Opracowanie osobistego radaru 341
Radar technologiczny firmy ThoughtWorks 341
Wizualizacje open source 344
Korzystanie z mediów społecznościowych 345
Kilka rad na pożegnanie 346
A. Pytania sprawdzające 347
360
stron, oprawa miękka