Twoja architektura działa.
Dopóki świat się nie zmieni.

Residuality Theory w praktyce PHP

Wszystkie testy są zielone. Czy architektura jest dobra?

Leszek Prabucki · PHPers · 16.09.2026

PUNKT WYJŚCIA

Nasz sklep działa

Klient → PHP-FPM → Orders DB → Mail API → HTTP 201

ZAŁOŻENIE 1

User = nabywca = płatnik

ZAŁOŻENIE 2

Mail API jest dostępne

ZAŁOŻENIE 3

Wszystko kończy się w jednym HTTP request

„Naïve architecture” = punkt wyjścia oparty na obecnym rozumieniu świata, nie zły kod.

RESIDUALITY THEORY · BARRY M. O’REILLY

Nie przewiduj całej przyszłości,
ale podważaj model architektury.

Przy których założeniach nasza architektura przestaje być optymalna? Co pozostanie, kiedy te założenia się spełnią? Jak zachowa się nasz system?

STRESSOR

Czym jest stresor?

Stresorem może być zdarzenie realistyczne lub zupełnie absurdalne, z pogranicza „nieznanych niewiadomych”. Celem nie jest idealne trafienie w przyszłość, ale sprawdzenie zachowania architektury pod wpływem losowych anomalii.

Stresory nie ograniczają się tylko do awarii sprzętu czy przeciążenia infrastruktury.

STRESSOR

Stresor nie musi być awarią

AWARIA

Mail API
nie odpowiada

ZMIANA BIZNESU

Firma chce kupować B2B

SUKCES

Sprzedaż rośnie ×100

Stresor = fakt, którego nie uwzględnia nasz model

RESIDUE

Co właściwie pozostaje?

01

STRESOR

→

02

CO POZOSTAŁO?

→

03

REAKCJA BIZNESU

→

04

ULEPSZONE RESIDUE

Residue nie jest komponentem.
To stan systemu po stresie - dobry, zły albo niewystarczający.

CASE STUDY · STRESOR TECHNICZNY

Mail padł. Zamówienie też?

$orderId = $this->orders->add($cart);       // DB ✓
$this->mailer->sendConfirmation($orderId); // ✕

return $this->response->created($orderId);  // —

Zamówienie istnieje ✓

Mail nie wyszedł ✕

Klient widzi błąd ✕

Czy brak maila ma anulować zakup?

Założenie przykładu: zapis zamówienia został już zatwierdzony.

REAKCJA BIZNESOWA → MECHANIZM

Kolejka jest skutkiem decyzji

$orderId = $this->db->transactional(function () use ($cart) {
    $id = $this->orders->add($cart);
    $this->outbox->append(new OrderPlaced($id));

    return $id;
});

return $this->response->created($orderId);

JEDNA TRANSAKCJA

Orders + Outbox

↓

Worker

↓

Mail API

Order: accepted  ·  Notification: pending / failed / sent 

CASE STUDY · STRESOR BIZNESOWY

Nic nie padło. Klient przestał być użytkownikiem

BYŁO

User = loguje się = zamawia = kupuje = płaci

PRACOWNIK

składa zamówienie

FIRMA

jest nabywcą

PRZEŁOŻONY

zatwierdza

KSIĘGOWOŚĆ

rozlicza

+ isCompany  ≠  rozdzielenie znaczeń i odpowiedzialności

ATTRACTOR + LOOPING

Nowa przyczyna. Znana konfiguracja

Mail API nie działa

Konto dostawcy zawieszone

Nowe integracja dla zamówień z WMD

→

POWRACAJĄCA KONFIGURACJA

Zamiar biznesowy przyjęty.
Zewnętrzny efekt czeka.

Osobny konsument do obsługi.

Attractor: powracająca konfiguracja  ·  Looping: nowe stresory korzystają z wcześniejszych pozostałości

RESIDUAL ARCHITECTURE

Residues trzeba jeszcze połączyć

MAIL UNAVAILABLE

Outbox + worker

B2B

Rozdzielone role

HTTP OVERLOAD

Izolacja procesów i wydzielenie ich z głownego procesu HTTP

↘          ↓          ↙

Jedna spójna architektura

Integracja ujawnia styki: wspólna baza · wspólna kolejka · sprzeczne statusy

CONTAGION ANALYSIS

Wpływ stresorów na moduły

1 = wpływ przy przyjętych założeniach. 0 nie oznacza wiecznej odporności.

ROZWAŻYĆ ≠ WDROŻYĆ

01

Zbuduj teraz

02

Zostaw tanią opcję adaptacji

03

Udokumentuj i obserwuj

Najpierw odkrywamy. Potem wracamy do kosztu, niezawodności i kompromisów. To można ładnie połączyć z architekturą ewolucyjną i funkcjami dopasowania (fitness function)

ITERACJA

Cała metoda, nie tylko burza mózgów

Punkt
wyjścia

→

Flow
analysis

→

Stresory
+ residues

→

Integracja
+ contagion

Koszt · ATAM · FMEA

→

Nowe stresory sprawdzające

↺

Każdy obrót pętli sprawdza skutki wcześniejszych decyzji.

EMPIRYCZNE SPRAWDZENIE

Testuj na czymś, czego nie użyłeś do projektowania

Zestaw projektowy ≠ zestaw sprawdzający

ARCHITEKTURA A

Punkt wyjścia

ARCHITEKTURA B

Residual architecture

TEN SAM ZESTAW
NOWYCH STRESORÓW

działa  /  adaptuje się z kosztem  /  nie radzi sobie

Najpierw ustal, co w tej historii znaczy „przetrwanie”.

Nie broń diagramu.
Sprawdzaj jego założenia.

Stresor podważa model, i to nie tylko obciążenie czy wolumen ruchu sieciowego.
Residue pokazuje, co pozostało i czego name brakuje.
Integruj odpowiedzi - i stresuj ponownie.

Co pozostanie z naszego systemu,
kiedy przestaniemy mieć rację?

Źródła

PODSTAWA

Barry M. O’Reilly
Residues: Time, Change, and Uncertainty in Software Architecture

Software Architektur im Stream #279
software-architektur.tv/transcriptions/279.html