Szkolenia Projektowanie i architektura

Projektowanie architektury oprogramowania zaczyna się od zrozumienia celów biznesowych, ograniczeń technicznych oraz atrybutów jakości, takich jak skalowalność, dostępność i bezpieczeństwo. W praktyce warto najpierw uporządkować wymagania funkcjonalne i niefunkcjonalne, zidentyfikować interesariuszy oraz zapisać kluczowe decyzje i kompromisy. Przykładem może być wybór między monolitem a mikroserwisami po analizie ryzyka, zespołów i sposobu wdrażania. Ten temat przerabiamy praktycznie na szkoleniu: Wprowadzenie do architektury oprogramowania.

Domain-Driven Design to podejście do modelowania złożonych domen i organizowania architektury wokół języka biznesowego, a Event Storming to technika warsztatowa służąca do odkrywania procesów, reguł i granic systemu. Najlepiej sprawdzają się razem, gdy trzeba przełożyć wiedzę domenową na bounded contexts, modele odpowiedzialności i decyzje architektoniczne. Przykładowo zespoły mogą najpierw rozpisać zdarzenia domenowe na warsztacie, a następnie na tej podstawie wyznaczyć konteksty i komunikację między nimi. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Projektowanie modeli domen z wykorzystaniem Domain-Driven Design i Event Storming.

Style architektoniczne różnią się sposobem podziału odpowiedzialności, integracji komponentów oraz kosztami utrzymania i zmian. Przy wyborze warto sprawdzić złożoność domeny, wymagania dotyczące niezależnych wdrożeń, odporności, spójności danych i dojrzałości zespołów. Dobrym przykładem jest pozostanie przy modularnym monolicie, gdy system ma wspólny model danych i niewielką liczbę niezależnych strumieni zmian, zamiast przedwczesnego przejścia na mikroserwisy. To jedno z zagadnień omawianych podczas szkolenia: Architektura systemowa i integracja systemów.

Event Storming służy do wspólnego odkrywania przebiegu procesów biznesowych, zdarzeń domenowych, hotspotów i miejsc wymagających decyzji projektowych. W praktyce trzeba ustalić cel sesji, dobrać uczestników z różnych obszarów, uporządkować chronologię zdarzeń i obserwować miejsca, w których zmienia się język, odpowiedzialność albo model pojęciowy. Przykładem wyznaczania bounded contexts jest rozdzielenie obszarów zamówień, płatności i wysyłki, gdy każdy z nich ma inne reguły i inny rytm zmian. Ten temat przerabiamy praktycznie na szkoleniu: Big Picture Event Storming.

CQRS rozdziela modele zapisu i odczytu, a Event Sourcing zapisuje historię zmian jako sekwencję zdarzeń zamiast utrwalać wyłącznie bieżący stan. Przed wdrożeniem trzeba sprawdzić wymagania dotyczące audytowalności, rekonstrukcji stanu, złożoności procesów i akceptacji dla eventual consistency, bo te wzorce zwiększają elastyczność, ale też komplikują model operacyjny. Typowym błędem jest stosowanie ich w prostych systemach CRUD, gdzie koszt utrzymania przewyższa korzyści architektoniczne. Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Event Sourcing i CQRS.

Dokumentowanie architektury polega na opisywaniu istotnych decyzji, ich uzasadnienia, konsekwencji oraz widoków systemu potrzebnych różnym interesariuszom. Warto sprawdzić, które elementy wymagają trwałego zapisu, a następnie dobrać lekkie artefakty, takie jak ADR do decyzji oraz UML, C4 lub ArchiMate do przedstawiania struktury i zależności. Przykładem może być zapisanie decyzji o komunikacji asynchronicznej w ADR i uzupełnienie jej diagramem kontekstowym oraz diagramem kontenerów. Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Wprowadzenie do architektury oprogramowania dla analityków.