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

W architekturze chodzi o ważne rzeczy (czymkolwiek to jest).

Ralph Johnson

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