Эволюционная архитектура. Проекты

Architektura ewolucyjna. Projektowanie oprogramowania i wsparcie zmian. Wydanie II

Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage

Jeszcze kilka lat temu koncepcja ewoluowania architektury była uznawana za zbyt odważną. Uważano, że architektura powinna pozostawać elementem niezmiennym w czasie. Jednak rzeczywistość udowadnia, że systemy muszą ewoluować, aby spełniać wymogi użytkowników i odzwierciedlać zmiany w dynamicznym środowisku tworzenia oprogramowania. Innymi słowy, konieczne się staje budowanie architektur ewolucyjnych.

Dzięki tej książce dowiesz się, w jaki sposób uczynić architekturę oprogramowania wystarczająco plastyczną, aby mogła odzwierciedlać zachodzące zmiany biznesowe i technologiczne. W nowym wydaniu rozbudowano pojęcia zmiany kierowanej i przyrostowej, a także przedstawiono najnowsze techniki dotyczące funkcji dopasowania, automatycznego zarządzania architekturą i danych ewolucyjnych. Zaprezentowano praktyki inżynieryjne umożliwiające ewoluowanie systemów oprogramowania, jak również podejścia strukturalne, w tym zasady projektowe, które ułatwiają zarządzanie tą ewolucją. Opisano ponadto, w jaki sposób zasady i praktyki architektury ewolucyjnej wiążą się z różnymi elementami procesu tworzenia oprogramowania.

Naucz się postrzegać architekturę systemową jako plastyczny wyzwalacz.

Sam Newman, architekt, autor książki Budowanie mikrousług

Najciekawsze zagadnienia:

• mechanika architektury ewolucyjnej
• zarządzanie projektami oprogramowania i ich ewolucją
• style architektoniczne i zasady projektowania
• sprzęganie i wieloużywalność
• łączenie praktyk inżynieryjnych z kwestiami strukturalnymi

Poznaj techniki umożliwiające tworzenie architektur oprogramowania na tyle zwinnych, aby dotrzymywały kroku ciągłym zmianom.

O autorach

Neal Ford jest architektem aplikacji w ThoughtWorks, międzynarodowej firmie konsultingowej z branży IT. Jest autorem programów komputerowych, artykułów i książek z dziedziny informatyki. Udziela konsultacji w zakresie projektowania i budowania dużych aplikacji korporacyjnych, a także prowadzi internetowe wykłady dla wojska i wielu firm z całego świata, wpisanych na listę „Fortune 500”.

Dr Rebecca Parsons od dziesięcioleci zajmuje się inżynierią oprogramowania, w tym wielkoskalowymi rozproszonymi aplikacjami obiektowymi, integracją systemów, optymalizacją oprogramowania, teorią obliczeń, uczenia maszynowego i biologii obliczeniowej.

Patrick Kua słynie z umiejętności równoważenia technologii, ludzi i procesu w celu zwiększenia efektywności zespołu. Na wielu konferencjach wygłasza referaty na temat architektury i tworzenia silnej kultury inżynieryjnej.

Pramod Sadalage specjalizuje się w projektach aplikacji i ewolucyjnych baz danych, architekturze danych i bazach danych NoSQL.

Spis treści:

Przedmowa do wydania pierwszego

Przedmowa do wydania drugiego

Wprowadzenie

Część I. Mechanika

• 1. Ewoluowanie architektury oprogramowania

  Wyzwania związane z ewoluującą architekturą

  Architektura ewolucyjna

  Zmiana kierowana

  Wielowymiarowość architektury

  Jak można planować coś długoterminowo, gdy wszystko zmienia się bez przerwy?

  W jaki sposób możemy po stworzeniu architektury zabezpieczyć ją przed degradacją?

  Dlaczego ewolucyjna?

  Podsumowanie

• 2. Funkcje dopasowania

  Czym jest funkcja dopasowania?

  Kategorie

  Zakres: atomowe/holistyczne

  Miarowość: wywoływane/ciągłe/czasowe

  Analiza przypadku: wywoływane czy ciągłe?

  Rezultat: statyczne/dynamiczne

  Wywołanie: zautomatyzowane/ręczne

  Proaktywność: zamierzone/wyłaniające się

  Pokrycie: funkcje dopasowania specyficzne dla domeny?

  Kto pisze funkcje dopasowania?

  Gdzie znajduje się platforma testowania moich funkcji dopasowania?

  Rezultaty a implementacje

  Podsumowanie

• 3. Projektowanie zmian przyrostowych

  Zmiana przyrostowa

  Potoki wdrażania

  Analiza przypadku: dodawanie funkcji dopasowania do usługi fakturowania w firmie Kapitalne Patenty

  Analiza przypadku: sprawdzanie spójności API w automatycznych kompilacjach

  Podsumowanie

• 4. Automatyzacja zarządzania architekturą

  Funkcje dopasowania w zarządzaniu architekturą

  Funkcje dopasowania na poziomie kodu

  Sprzężenie aferentne i eferentne

  Abstrakcyjność, niestabilność i odległość od głównej sekwencji

  Kierunkowość importowanych elementów

  Złożoność cyklomatyczna i zarządzanie przez kierowanie zespołami

  Kompletne narzędzia

  Legalność otwartych bibliotek

  A11y i inne obsługiwane parametry architektury

  ArchUnit

  Lintery do zarządzania kodem

  Analiza przypadku: funkcja dopasowania dostępności

  Analiza przypadku: testowanie obciążenia wraz z wydaniami kanarkowymi

  Architektura integracji

  Zarządzanie komunikacją w mikrousługach

  Analiza przypadku: wybór sposobu implementacji funkcji dopasowania

  DevOps

  Architektura korporacyjna

  Analiza przypadku: restrukturyzacja architektury podczas 60 wdrożeń dziennie

  Funkcje dopasowania wierności

  Funkcje dopasowania jako lista kontrolna, a nie kij samobij

  Dokumentowanie funkcji dopasowania

  Podsumowanie

Część II. Struktura

• 5. Topologie architektury ewolucyjnej

  Struktura architektury ewolucyjnej

  Splątanie

  Skrzyżowanie splątania z ograniczonym kontekstem

  Kwanty architektury i ziarnistość

  Niezależnie wdrażany

  Wysoce funkcjonalna spójność

  Znaczne sprzężenie statyczne

  Kontrakty

  Analiza przypadku: mikrousługi jako architektura ewolucyjna

  Wzorce wieloużywalności kodu

  Skuteczna wieloużywalność = abstrakcja + mała ulotność

  Przyczepy i siatka usług: ortogonalne sprzężenie operacyjne

  Siatka danych: sprzężenie ortogonalne danych

  Podsumowanie

• 6. Dane ewolucyjne

  Projektowanie ewolucyjnej bazy danych

  Integracja współdzielonych baz danych

  Nieprawidłowe nakładanie się danych

  Zatwierdzanie dwufazowe transakcji

  Wiek i jakość danych

  Analiza przypadku: ewolucja trasowania w firmie Kapitalne Patenty

  Od funkcji natywnej do funkcji dopasowania

  Zgodność powiązań

  Duplikacja danych

  Zastępowanie wyzwalaczy i przechowywanych procedur

  Analiza przypadku: ewoluowanie od architektury relacyjnej do nierelacyjnej

  Podsumowanie

Część III. Skutki

• 7. Tworzenie ewoluowalnych architektur

  Zasady architektury ewolucyjnej

  Ostatni odpowiedzialny moment

  Projektuj i twórz z myślą o ewoluowalności

  Prawo Postela

  Projektuj z myślą o testowalności

  Prawo Conwaya

  Mechanika

  Etap 1. Identyfikacja wymiarów podlegających ewolucji

  Etap 2. Definiowanie funkcji dopasowania dla każdego wymiaru

  Etap 3. Stosowanie potoku wdrażania do automatyzacji funkcji dopasowania

  Nowe projekty

  Modernizowanie istniejących architektur

  Prawidłowe sprzężenie i spójność

  Skutki stosowania modelu COTS

  Migrowanie architektur

  Etapy migracji

  Ewoluowanie oddziaływań pomiędzy modułami

  Wskazówki dotyczące tworzenia architektur ewolucyjnych

  Usuń niepotrzebną zmienność

  Zagwarantuj odwracalność decyzji

  Przedkładaj ewoluowalność nad przewidywalność

  Twórz warstwy przeciwdegradacyjne

  Tworzenie architektur ofiarniczych

  Minimalizuj wpływ zmian zewnętrznych

  Aktualizowanie bibliotek i szkieletów

  Wersjonuj usługi wewnętrznie

  Analiza przypadku: ewoluowanie systemu oceniania w firmie Kapitalne Patenty

  Architektura sterowana funkcjami dopasowania

  Podsumowanie

• 8. Pułapki i antywzorce architektury ewolucyjnej

  Architektura techniczna

  Antywzorzec: pułapka ostatnich 10% i mało kodu/ brak kodu

  Analiza przypadku: wieloużywalność w firmie Kapitalne Patenty

  Antywzorzec: monopolista

  Pułapka: nieszczelne abstrakcje

  Pułapka: projektowanie zorientowane na CV

  Zmiany przyrostowe

  Antywzór: nieprawidłowe zarządzanie

  Analiza przypadku: zarządzanie "na styk" w firmie Kapitalne Patenty

  Pułapka: brak szybkości wydawania

  Kwestie biznesowe

  Pułapka: dostosowywanie produktu

  Antywzorzec: raportowanie na wierzchu systemu rekordów

  Pułapka: nadmiernie długie horyzonty planowania

  Podsumowanie

• 9. Stosowanie architektury ewolucyjnej w praktyce

  Czynniki organizacyjne

  Nie walcz z prawem Conwaya

  Parametry sprzężenia zespołów

  Kultura

  Kultura eksperymentowania

  Dyrektor finansowy i przygotowywanie budżetu

  Kwestia biznesowa

  Projektowanie zorientowane na hipotezy i dane

  Funkcje dopasowania jako media eksperymentalne

  Tworzenie korporacyjnych funkcji dopasowania

  Analiza przypadku: podatność zabezpieczeń na ataki dnia zerowego

  Wyznaczanie ograniczonych kontekstów w istniejącej architekturze integracji

  Od czego zacząć?

  Łatwo osiągalny cel

  Przede wszystkim największa wartość

  Testowanie

  Infrastruktura

  Analiza przypadku: architektura korporacyjna w firmie Kapitalne Patenty

  Stan przyszły?

  Testowanie generatywne

  Dlaczego (lub dlaczego nie)?

  Dlaczego firma powinna zdecydować o tworzeniu architektury ewolucyjnej?

  Dlaczego firma miałaby rezygnować z tworzenia architektury ewolucyjnej?

  Podsumowanie