Description

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 architektoniczneetapy pracy przy projektowaniu nowoczesnej architekturyumiejętności miękkie pomocne w pracy architektanowe praktyki w projektowaniu architektury oprogramowaniaarchitektura oprogramowania jako dziedzina inżynieriiW architekturze chodzi o ważne rzeczy (czymkolwiek to jest).Ralph JohnsonSpis treści:Przedmowa: obalanie aksjomatów 131. Wprowadzenie 17Zdefiniowanie architektury oprogramowania 19Oczekiwania wobec architekta 22Podejmowanie decyzji architektonicznych 23Ciągłe analizowanie architektury 23Śledzenie najnowszych trendów 24Zapewnienie zgodności z decyzjami 24Bogate i zróżnicowane doświadczenie 25Wiedza z zakresu biznesu 25Umiejętności interpersonalne 26Znajomość i umiejętność stosowania polityki firmy 26Punkty przecięcia architektury z innymi elementami 27Praktyki inżynieryjne 28Operacje (DevOps) 31Proces 32Dane 32Prawa architektury oprogramowania 33CZĘŚĆ I. PODSTAWY2. Myślenie architektoniczne 37Architektura a projekt 38Rozpiętość techniczna 39Analiza kompromisów 43Czynniki biznesowe 46Zachowanie równowagi między architekturą a kodowaniem 473. Modułowość 49Definicja 50Pomiar modułowości 52Spójność 52Sprzężenie 55Abstrakcyjność i niestabilność 56Odległość od ciągu głównego 57Splątanie 59Unifikacja wskaźników sprzężenia i splątania 63Od modułów do składników 644. Definiowanie parametrów architektury 65(Niepełna) lista parametrów architektury 68Operacyjne parametry architektury 68Strukturalne parametry architektury 69Przekrojowe parametry architektury 69Kompromisy i najmniej niekorzystna architektura 735. Identyfikacja parametrów architektury 75Określanie parametrów architektury na podstawie zagadnień dziedzinowych 75Określanie parametrów architektury na podstawie wymagań 77Studium przypadku: Krzemowe Kanapki 79Parametry sprecyzowane 79Parametry dorozumiane 836. Pomiar parametrów architektury i zarządzanie nimi 85Pomiar parametrów architektury 85Pomiary operacyjne 86Pomiary strukturalne 87Pomiary procesowe 89Funkcje zarządzania i dopasowania 89Zarządzanie parametrami architektury 89Funkcje dopasowania 907. Zakres parametrów architektury 97Sprzężenie i splątanie 97Kwanty architektury i ziarnistość 98Studium przypadku: „Po raz pierwszy, po raz drugi, sprzedane!” 1008. Myślenie w oparciu o składniki 105Zakres składnika 105Rola architekta 106Podział architektury 107Studium przypadku: Krzemowe Kanapki – podział 110Rola programisty 112Proces identyfikacji składników 113Identyfikacja składników początkowych 113Przypisywanie wymagań do składników 113Analiza ról i odpowiedzialności 114Analiza parametrów architektury 114Restrukturyzacja składników 114Szczegółowość składników 114Projektowanie składników 114Odkrywanie składników 115Studium przypadku: „Po raz pierwszy, po raz drugi, sprzedane!” – odkrywanie składników 117Jeszcze raz o kwantach architektury: wybór między architekturą monolityczną a rozproszoną 120CZĘŚĆ II. STYLE ARCHITEKTONICZNE9. Podstawy 123Podstawowe wzorce 123Bryła błotna 123Architektura unitarna 125Klient-serwer 125Architektury monolityczne a rozproszone 127Mit 1. Sieć jest niezawodna 127Mit 2. Opóźnienie jest zerowe 128Mit 3. Przepustowość jest nieskończona 129Mit 4. Sieć jest bezpieczna 130Mit 5. Topologia nigdy się nie zmienia 131Mit 6. Jest tylko jeden administrator 131Mit 7. Koszt transportu jest zerowy 132Mit 8. Sieć jest homogeniczna 133Inne kwestie związane z rozproszeniem 13310. Styl architektury warstwowej 135Topologia 135Warstwy izolacji 137Dodawanie warstw 138Inne kwestie 139Dlaczego warto stosować ten styl architektoniczny? 140Ocena parametrów architektury 14111. Styl architektury potokowej 143Topologia 143Potoki 144Filtry 144Przykład 145Ocena parametrów architektury 14612. Styl architektury mikrojądra 149Topologia 149Podstawowy system 150Dołączane składniki 151Rejestr 155Kontrakty 156Przykłady i przypadki użycia 156Ocena parametrów architektury 15713. Styl architektury bazującej na usługach 161Topologia 161Warianty topologii 162Projektowanie usług i ich szczegółowość 164Podział bazy danych 166Przykład architektury 168Ocena parametrów architektury 169Kiedy należy używać tego stylu architektonicznego? 17214. Styl architektury sterowanej zdarzeniami 173Topologia 174Topologia brokera 174Topologia mediatora 179Komunikacja asynchroniczna 186Obsługa błędów 188Zapobieganie utracie danych 191Rozgłaszanie 193Żądanie-odpowiedź 193Wybór między modelem opartym na żądaniach a modelem opartym na zdarzeniach 196Architektury hybrydowe sterowane zdarzeniami 196Ocena parametrów architektury 19715. Styl architektury przestrzennej 201Ogólna topologia 202Jednostka przetwarzająca 203Zwirtualizowane oprogramowanie pośredniczące 203Pompy danych 208Jednostki zapisu danych 210Jednostki odczytu danych 211Kolizje danych 212Wdrożenia chmurowe a lokalne 215Buforowanie replikowane a rozproszone 215Model near-cache 218Przykłady wdrożeń 219System sprzedaży biletów na koncerty 220System aukcji internetowych 220Ocena parametrów architektury 22116. Architektura zorientowana na usługi sterowana orkiestracją 223Historia i filozofia 223Topologia 224Taksonomia 224Usługi biznesowe 224Usługi korporacyjne 225Usługi aplikacji 225Usługi infrastrukturalne 225Silnik orkiestracji 225Przepływ komunikatów 226Wykorzystuj ponownie… i sprzęgaj 227Ocena parametrów architektury 22917. Architektura mikrousług 231Historia 231Topologia 232Rozproszenie 233Ograniczony kontekst 233Poziom szczegółowości 234Izolacja danych 234Warstwa API 235Wieloużywalność operacyjna 235Interfejsy 238Komunikacja 239Choreografia i orkiestracja 241Transakcje i sagi 243Ocena parametrów architektury 247Dodatkowe informacje 24818. Wybór odpowiedniego stylu architektonicznego 249Zmiana „mody” w architekturze 249Kryteria decyzyjne 250Studium przypadku architektury monolitycznej: Krzemowe Kanapki 253Monolit modułowy 253Mikrojądro 254Studium przypadku architektury rozproszonej: „Po raz pierwszy, po raz drugi, sprzedane!” 255CZĘŚĆ III. TECHNIKI I UMIEJĘTNOŚCI MIĘKKIE19. Decyzje architektoniczne 261Antywzorce w decyzjach architektonicznych 261Antywzorzec Obrona Swojego Stanowiska 261Antywzorzec Dzień Świstaka 262Antywzorzec Architektura Sterowana Wiadomościami E-mail 263Istotność architektoniczna 264Rejestr decyzji architektonicznych 264Podstawowa struktura 265Przechowywanie dokumentów ADR 270ADR jako dokumentacja 272Wykorzystanie dokumentów ADR do standaryzacji 272Przykład 27320. Analiza ryzyka w architekturze 275Macierz ryzyka 275Ocena ryzyka 276Risk storming 279Identyfikacja 281Konsensus 281Ograniczanie 283Analizy ryzyka historyjek w metodykach zwinnych 285Przykłady risk stormingu 285Dostępność 286Elastyczność 288Bezpieczeństwo 28921. Tworzenie diagramów i prezentacja architektury 293Diagramy 294Narzędzia 294Standardy tworzenia diagramów: UML, C4 i ArchiMate 296Wskazówki dotyczące sporządzania diagramów 297Prezentacja 298Manipulowanie czasem 299Diagramy przyrostowe 299Karty informacyjne a prezentacje 300Slajdy to połowa przekazu 302Niewidoczność 30222. Zwiększanie efektywności zespołów 303Granice zespołów 303Osobowości architektów 304Maniak kontroli 304Architekt fotelowy 306Skuteczny architekt 307Poziom kontroli 308Znaki ostrzegawcze w zespole 312Wykorzystanie list kontrolnych 315Lista kontrolna gotowości kodu 317Lista kontrolna testów jednostkowych i funkcjonalnych 318Lista kontrolna wydania oprogramowania 318Udzielanie wskazówek 319Podsumowanie 32123. Umiejętności negocjacyjne i zdolności przywódcze 323Negocjacje i facylitacja 323Negocjacje z interesariuszami biznesowymi 324Negocjacje z innymi architektami 326Negocjacje z programistami 327Architekt oprogramowania jako lider 328Cztery aspekty architektury 328Bądź pragmatyczny, ale zarazem wizjonerski 330Przewodzenie zespołom poprzez dawanie przykładu 331Integracja z zespołem 335Podsumowanie 33824. Rozwijanie ścieżki kariery zawodowej 339Zasada 20 minut 339Opracowanie osobistego radaru 341Radar technologiczny firmy ThoughtWorks 341Wizualizacje open source 344Korzystanie z mediów społecznościowych 345Kilka rad na pożegnanie 346A. Pytania sprawdzające 347

Informatyka

toples plaza, wydazenia, europejski kongres gospodarczy 2019, lidl rzym, 11 listopada w warszawie

yyyyy