Architektura oprogramowania

Projektowanie architektury oprogramowania warto zacząć od ustalenia celów biznesowych, ograniczeń technicznych oraz atrybutów jakości, takich jak skalowalność, dostępność i bezpieczeństwo. Następnie trzeba przełożyć wymagania funkcjonalne i niefunkcjonalne na decyzje dotyczące dekompozycji, komunikacji i własności danych. Przykładowo, system obsługujący duży ruch może wymagać innego podejścia niż aplikacja wewnętrzna z prostym modelem integracji.
Ten temat przerabiamy praktycznie na szkoleniu: Wprowadzenie do architektury oprogramowania (ARCH/INTRO).

DDD i mikroserwisy rozwiązują różne problemy, choć często występują razem w jednym podejściu architektonicznym. Najpierw warto sprawdzić, czy domena rzeczywiście wymaga wyraźnych granic odpowiedzialności, Bounded Contextów i niezależnego rozwoju komponentów, a dopiero później decydować o podziale wdrożeniowym. Przykładem może być organizacja, która zaczyna od modelowania domeny Event Stormingiem, a dopiero potem wydziela serwisy zgodnie z granicami biznesowymi.
Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Architektura Mikroserwisów z wykorzystaniem Domain-Driven Design oraz Event Storming (MICROSERVICES/DDD).

Dokumentowanie architektury powinno obejmować zarówno widoki systemu, jak i uzasadnienie decyzji technicznych. W praktyce warto sprawdzić, czy dokumentacja zawiera kontekst, granice komponentów, zależności oraz zapis kompromisów w formie ADR, a diagramy są czytelne dla różnych grup interesariuszy. Dobrym przykładem jest połączenie modelu C4 do opisu struktury systemu z ADR do utrwalania decyzji o wyborze stylu komunikacji lub sposobu integracji.
To jedno z zagadnień omawianych podczas szkolenia: Wprowadzenie do architektury oprogramowania dla analityków (ARCH/INTRO/ANA).

Testowanie architektury mikroserwisów obejmuje weryfikację kontraktów, odporności komunikacji, zachowania przy awariach oraz zgodności implementacji z przyjętymi regułami. Trzeba sprawdzić między innymi granice serwisów, scenariusze częściowej niedostępności, obsługę retry, timeoutów i spójność danych w przepływach asynchronicznych. Przykładem są testy kontraktowe API, testy architektoniczne w ArchUnit oraz kontrolowane scenariusze awarii dla komunikacji synchronicznej i zdarzeniowej.
Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Architektura Mikroserwisów na platformie Java (MICROSERVICES).

W architekturze oprogramowania najczęściej stosuje się narzędzia i notacje, które porządkują widoki systemu, zależności oraz decyzje projektowe. Warto sprawdzić, czy dany zestaw wspiera różne poziomy szczegółowości, od kontekstu biznesowego po komponenty i relacje techniczne, a także czy nadaje się do pracy z zespołami technicznymi i analitycznymi. Typowym przykładem są UML, model C4, ArchiMate i Architecture Decision Record używane równolegle w jednym projekcie.
Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Wprowadzenie do architektury oprogramowania (ARCH/INTRO).

Architektura zdarzeniowa opiera się na wymianie zdarzeń między producentami i konsumentami bez ścisłego sprzężenia czasowego. Należy sprawdzić model zdarzeń, kolejność przetwarzania, sposób obsługi duplikatów, granice odpowiedzialności oraz to, czy lepsze będzie podejście stateless czy stateful. Przykładem jest system integrujący wiele usług przez brokera zdarzeń, gdzie osobno projektuje się kanały komunikacyjne, formaty wiadomości i mechanizmy reakcji na opóźnienia.
Ten temat przerabiamy praktycznie na szkoleniu: Event-Driven Architecture (EDA).