Rozważmy kasę, w której płatność się udaje, ale aktualizacja zamówienia kończy się błędem. Klient widzi komunikat o błędzie i próbuje ponownie. W międzyczasie dział wsparcia ma zapis transakcji, magazyn nie ma potwierdzonego zamówienia, a dział finansowy musi wiedzieć, czy klient cokolwiek winien.

Który system powinien rozstrzygnąć taką sytuację? To właśnie w takich incydentach uwidaczniają się decyzje architektoniczne: gdy własność jest niezdefiniowana, każde wystąpienie otrzymuje ręcznie skleconą poprawkę, a te poprawki kumulują się tam, gdzie najłatwiej je napisać.

Architektura powinna odpowiedzieć na to pytanie, zanim pierwsza transakcja trafi na produkcję W przeciwnym razie kod płatności stopniowo wchłania odzyskiwanie zamówień, zasady subskrypcji, korekty faktur i decyzje dotyczące realizacji.

Przedstawiony poniżej model własności oferuje praktyczny punkt wyjścia: utrzymuj bramkę skupioną na komunikacji z dostawcą, daj operacjom płatniczym własny dom, a decyzje komercyjne zostaw fakturowaniu i zamówieniom.

Zacznij od czterech odpowiedzialności, a nie trzech

W tym projekcie odróżnij bramkę płatności od szerszej usługi płatności. Model wykorzystuje cztery logiczne granice obejmujące bramkę, usługę płatności, fakturowanie i zamówienia.

Traktuj je jako granice własności, a nie nakaz wdrożenia czterech mikrousług. Zacznienie od modułów wewnątrz jednej aplikacji jest w porządku, jeśli to odpowiada zespołowi. W każdym razie odpowiedzialności powinny być jawne.

Analizując architekturę bramki płatności, połącz diagram komponentów z mapą decyzji: kto decyduje o kwocie, kto żąda pobrania, kto rejestruje wynik i kto autoryzuje kolejną akcję biznesową?

Utrzymuj bramkę blisko dostawcy

Daj bramce wąski kontrakt. Powinna przyjmować obsługiwaną operację płatniczą, tłumaczyć ją na format dostawcy i zwracać wynik, który usługa płatności potrafi zinterpretować.

Ta izolacja ma praktyczne uzasadnienie: dostawcy płatności różnią się interfejsami API, schematami uwierzytelniania, formatami pól i mechanizmami powiadomień, a skonsolidowanie tej zmienności w jednej warstwie izoluje resztę systemu od specyfiki dostawców.

Przypisz jej odpowiedzialności takie jak:

• Walidacja żądania skierowanego do dostawcy
• Uwierzytelnianie komunikacji z dostawcą
• Tłumaczenie pól wewnętrznych na pola specyficzne dla dostawcy
• Weryfikacja przychodzących powiadomień dostawcy
• Mapowanie odpowiedzi przy zachowaniu użytecznych szczegółów dostawcy

Wiedza o produkcie pozostaje poza tym kontraktem. Bramka nie powinna musieć rozumieć poziomów lojalnościowych, uprawnień do wysyłki, okresów karencji subskrypcji ani pakietów promocyjnych. Przekazuj jej zatwierdzoną kwotę, walutę, referencję płatności i wymagane informacje o metodzie płatności — a nie reguły, które je wygenerowały.

Pożyteczne pytanie kontrolne: czy zmiana polityki zwrotów wymagałaby zmiany kodu bramki? Jeśli tak, przemyśl granicę.

Daj operacjom płatniczym osobnego właściciela

Próby płatności i ich wyniki należą do usługi płatności Dla każdej próby rejestruj wewnętrzny identyfikator, istotne referencje dostawcy, żądaną kwotę, walutę, typ operacji i stan. Zachowaj wystarczającą historię, by zbadać, o co wnioskowano i co faktycznie potwierdzono.

Unikaj sprowadzania modelu do pojedynczej flagi „paid”. Zamiast tego zdefiniuj rozróżnienia, których potrzebują przepływy pracy, w tym wyniki nierozstrzygnięte. Komunikacja z dostawcą bywa rzeczywiście niepewna — przekroczenia czasu, spóźnione powiadomienia i aktualizacje poza kolejnością są na porządku dziennym — więc model stanów musi mieć miejsce na niejednoznaczność, zamiast sprowadzać każdy wynik do sukcesu lub porażki.

Zaprojektuj jawnie dla tej hipotetycznej sekwencji: usługa płatności żąda autoryzacji, żądanie dociera do dostawcy, a odpowiedź ginie. Aplikacja musi wtedy zdecydować, co dalej. Przekroczenie czasu nigdy nie powinno automatycznie wywoływać nowego obciążenia. Wymagaj, aby usługa płatności rozstrzygnęła lub bezpiecznie zarządziła pierwotną próbą, zanim dopuszczona zostanie kolejna operacja.

Rozdziel też dwa rodzaje ponowień:

• Ponowienie techniczne: powtórzenie komunikacji dla tej samej zamierzonej operacji zgodnie z określonymi regułami bezpieczeństwa.
• Ponowienie pobrania: nowa próba ściągnięcia zaległego salda.

Obsługę ponowień technicznych przypisz projektowi integracji płatniczej. Fakturowanie określa termin i uprawnienia do pobrania, a usługa płatności wykonuje zatwierdzoną próbę.

Pozwól fakturowaniu decydować, co jest należne

Fakturowanie jest właścicielem zobowiązania finansowego: wyliczenia opłaty, faktury, kredytów i pozostałego salda. Dla produktu subskrypcyjnego reguły zmian planów, proporcjonalnego rozliczania, okresów rozliczeniowych i harmonogramów pobrania należą tutaj.

Wymagaj, aby fakturowanie wystawiało każde żądanie pobrania z jawną kwotą, walutą i referencją do ściaganego zobowiązania. Usługa płatności raportuje wynik, a następnie fakturowanie określa, jak ten wynik wpływa na saldo.

Rozważ hipotetyczną fakturę na 100 USD z kredytem 30 USD. Fakturowanie powinno zażądać pozostałych 70 USD. Nigdy nie należy prosić bramki o odtworzenie tego wyliczenia z metadanych subskrypcji.

Staw rosną wraz ze złożonością cen: każde wyliczenie, które trafi do niewłaściwego komponentu, staje się logiką, którą później trzeba odnaleźć, przenieść i uzgodnić między systemami.

Ta sama dyscyplina obowiązuje po zwrocie. Zapisy płatności ustalają, co zostało zwrócone przez dostawcę; fakturowanie określa, która faktura lub korekta salda odpowiada temu zwrotowi.

Pozwól zamówieniom decydować, co dzieje się z zakupem

Decyzje dotyczące realizacji i cyklu życia zakupu pozostają w domenie zamówień. Usługa płatności powinna publikować wynik płatności, a nie wydawać polecenia magazynowi, a przepływ zamówienia powinien interpretować ten wynik razem ze swoimi pozostałymi wymaganiami. Interpretacja wyniku to osąd biznesowy równie mocno jak techniczny, ponieważ to samo potwierdzenie płatności może mieć różną wagę dla różnych modeli realizacji.

Przykład jawnej reguły realizacji: zwolnij zamówienie tylko wtedy, gdy spełniony jest wymagany warunek płatności, zapas jest zarezerwowany, a wszelkie wymagane przeglądy zakończone. Warunek płatności należy dobrać do modelu biznesowego i nigdy nie chować go wewnątrz procedury obsługi odpowiedzi dostawcy.

Anulowania zasługują na tę samą separację. Zamówienia decydują, czy anulowanie jest dozwolone i co ma się stać z zakupem, a następnie żądają odpowiedniej operacji płatniczej przez usługę płatności. Unikaj przeciążonego polecenia „cancel”, które może oznaczać anuluj zamówienie, zwolnij autoryzację, zwróć płatność albo zakończ subskrypcję. Nadawaj każdej akcji precyzyjną nazwę.

Koordynuj zwroty, nie dając żadnemu systemowi wszystkich zadań

Przepływ zwrotu to dobry test, czy granice się trzymają. Załóżmy, że klient zwraca jeden przedmiot z zamówienia trzyelementowego. Zbuduj przepływ tak, aby:

• Komponent zwrotów lub zamówień zatwierdzał zwrot.
• Wyznaczony właściciel wyliczeń komercyjnych określał kwotę podlegającą zwrotowi.
• Usługa płatności sprawdzała historię płatności i obowiązujące limity operacji.
• Bramka przesyłała żądanie do dostawcy.
• Usługa płatności rejestrowała potwierdzony lub nierozstrzygnięty wynik.
• Fakturowanie i zamówienia odpowiednio aktualizowały własne zapisy.

Przypisz jednego właściciela do każdego wyliczenia. Fakturowanie i zamówienia nie powinny niezależnie wyliczać różnych kwot zwrotu i zostawiać płatności wybór między nimi.

Trzymaj „zwrot żądany” oddzielnie od „zwrot potwierdzony”. Jeśli wynik od dostawcy jest nierozstrzygnięty, zachowaj tę niepewność i zapewnij ścież dochodzenia, zamiast oznaczać cały przepływ jako zakończony.

Uczyń odzyskiwanie częścią kontraktu

Każda operacja przekraczająca granice powinna określać więcej niż samą odpowiedź sukcesu. Udokumentuj:

• Jak identyfikowane są powtarzające się żądania
• Który komponent jest właścicielem stanu autorytatywnego
• Jak obsługiwane są spóźnione lub zduplikowane powiadomienia
• Co się dzieje, gdy kolejny komponent jest niedostępny
• Jak pracownicy badają nierozstrzygnięte wyniki
• Które akcje mogą być bezpiecznie ponawiane

W szczególności dla powtarzających się żądań dostawcy powszechnie oferują mechanizmy idempotencji zaprojektowane dokładnie w tym celu, pozwalające ponownie wysłać tę samą operację bez jej podwójnego wykonania.

Daj każdej domenie własne identyfikatory i łącz je jawnie: ID zamówienia, ID faktury, ID płatności, ID próby i referencja dostawcy. Nie zmuszaj jednego identyfikatora do reprezentowania każdej relacji.

Pracownicy wsparcia mogą otrzymać połączoną oś czasu, ale korekty powinny pozostawać pod kontrolą komponentu-właściciela. Wygodny pulpit nie powinien stać się uprawnieniem do nadpisywania historii płatności ani po cichu zmieniania sald faktur.

Testuj granice zmianami biznesowymi

Przed zatwierdzeniem projektu przejdź przez kilka zmian:

• Dodaj dostawcę płatności bez zmiany reguł cenowych.
• Zmień termin pobrania subskrypcji bez edycji adapterów bramki.
• Wprowadź zwroty częściowe bez przepisywania obsługi powiadomień dostawcy.
• Zmień politykę realizacji bez zmiany definicji stanów płatności.

Traktuj nieoczekiwane zmiany międzykomponentowe jako sygnały do przeglądu. Część koordynacji jest uzasadniona; niewyjaśnione sprzężenia zasługują na uwagę.

Dryf własności rzadko się ogłasza; kumuluje się po jednym doraźnym->zmiana na raz. Ponowne przechodzenie tych scenariuszy przy każdym wprowadzeniu nowego dostawcy, metody płatności lub modelu cenowego utrzymuje granice jawne długo po początkowym przeglądzie projektu.

Bramka powinna kończyć się na komunikacji płatniczej skierowanej do dostawcy. Usługa płatności powinna być właścicielem wykonania płatności i dowodów. Fakturowanie powinno być właścicielem zobowiązań i sald. Zamówienia powinny być właścicielem zakupu i jegoacji.

Zapisz te odpowiedzialności w interfejsach, procedurach odzyskiwania i własności zespołowej. Sam diagram nie utrzyma ich osobno.