Sklep internetowy działa od kilku lat. Firma dostaje ofertę od innego operatora płatności, z niższą prowizją, i chce przejść. Wykonawca wycenia zmianę na kilka tygodni pracy, a do tego testy. Szef pyta, dlaczego tak długo, skoro klient dalej płaci kartą, tylko przez kogoś innego.

Podobnie bywa z programem księgowym. Biuro rachunkowe przechodzi na inny program, a aplikacja firmy co dzień wysyła do starego faktury i dane kontrahentów.

Ten artykuł dotyczy sytuacji, w której firma zostaje przy swojej aplikacji, a zmienia tylko jedną usługę zewnętrzną. Gdy zmienia się cały system, ważniejsze są dane i formaty, o których piszemy w artykułach Twoje dane w cudzym formacie i Standardy, których nie widać.

Dlaczego zmiana dostawcy bywa droga?

Każdy dostawca mówi trochę innym językiem. Jeden operator płatności chce kwotę w groszach, drugi w złotych. Jeden zgłasza odmowę karty jednym kodem, drugi kilkoma. Nowy program księgowy ma inne pola i inaczej nazywa stawki VAT.

Sama zmiana języka to niewielka praca. Kosztuje to, gdzie w aplikacji leży rozmowa z dostawcą. Jeśli jest w kilku miejscach, wymieszana z zasadami firmy, programista musi ją przerabiać w każdym z nich. Obok leżą przy tym warunki, które pilnują pieniędzy klientów: czy zamówienie należy do tego klienta, czy czeka na zapłatę, czy nie ma w nim wycofanych produktów. Każdą poprawkę w takim miejscu trzeba bardzo uważnie sprawdzić, bo błąd kosztuje więcej niż sama przeróbka. Klient zapłaci dwa razy albo do magazynu trafi zamówienie zapisane bez liczby sztuk.

Ile to kosztuje?

Konkretnej kwoty nie da się podać bez zajrzenia do aplikacji, ale da się powiedzieć, od czego zależy.

Gdy rozmowa z dostawcą jest w jednym miejscu aplikacji, zmiana dotyczy tylko tego miejsca. Programista pisze obsługę nowego dostawcy, sprawdza ją i przełącza. Zasady firmy zostają nietknięte, więc nie trzeba ich testować od nowa.

Gdy rozmowa z dostawcą jest rozsiana po aplikacji, płaci się za szukanie wszystkich takich miejsc, za przeróbki w każdym z nich i za sprawdzenie całości. Do tego dochodzi ryzyko, że któreś miejsce zostanie przeoczone i wyjdzie dopiero przy pierwszym nietypowym zamówieniu.

Jak to powinno być zbudowane?

Najłatwiej wyobrazić to sobie jako gniazdko i przejściówkę.

Kształt gniazdka ustala aplikacja. Mówi tylko, czego potrzebuje, na przykład „obciąż klienta tą kwotą i podaj numer płatności”, i nie interesuje jej, kto jest po drugiej stronie. Przejściówka z jednej strony pasuje do gniazdka, a z drugiej mówi językiem konkretnego dostawcy.

Zmiana dostawcy to wtedy nowa przejściówka. Ekran „Zapłać”, nocne ponawianie nieudanych płatności i panel administratora korzystają z tego samego gniazdka, więc nie ma kopii, które trzeba by przerabiać osobno. Zasady firmy da się przy tym sprawdzać szybkimi testami, z udawanym dostawcą, który przyjmuje albo odrzuca płatność. Samą przejściówkę sprawdza się osobno, na takiej samej bazie danych, na jakiej działa sklep.

Taki podział działa tylko wtedy, gdy nikt go nie omija. Wystarczy jeden skrót dopisany „na chwilę” i zasady firmy znowu wiedzą, z jakim dostawcą rozmawiają. Dlatego tej granicy powinien pilnować program, który sprawdza ją przy każdej zmianie.

Czy klient może zapłacić dwa razy?

Może, jeśli nikt o tym nie pomyślał. Klient klika „Zapłać”, a w tej samej chwili nocne ponawianie próbuje opłacić to samo zamówienie. Oba widzą je jako nieopłacone i karta zostaje obciążona dwa razy.

Zapobiega temu stan „płatność w toku”, który zamówienie dostaje, zanim aplikacja poprosi dostawcę o pieniądze. Drugie kliknięcie słyszy wtedy, że płatność już trwa. Potrzebne jest też zadanie, które regularnie sprawdza u dostawcy zamówienia z przerwaną płatnością, bo pieniądze mogły zostać pobrane, choć wynik się nie zapisał. Z tego samego powodu mail „dziękujemy za zapłatę” wychodzi dopiero wtedy, gdy wynik jest naprawdę zapisany. Wszystko to łatwiej zrobić raz, w jednym gniazdku, niż w każdym miejscu, które obsługuje płatność po swojemu.

Kiedy warto się przygotować?

Najtaniej przy budowie aplikacji, jeśli wiadomo, że będzie łączyć się z kilkoma usługami zewnętrznymi i ma działać latami. Drugi dobry moment to zapowiedź zmiany: kończy się umowa z operatorem płatności albo biuro rachunkowe uprzedza o nowym programie. Przy takiej zmianie warto od razu przenieść rozmowę z tym dostawcą w jedno miejsce.

Nie trzeba przy tym przepisywać całej aplikacji. Podział wprowadza się po kawałku, zaczynając od jednej usługi, na przykład płatności. Przez jakiś czas aplikacja żyje w dwóch stylach naraz i to jest w porządku. Kolejne miejsca wybiera się tam, gdzie coś boli: gdzie wracają te same błędy albo gdzie wymiana usługi jest już zapowiedziana.

Gdzie to się nie opłaca?

Taki podział ma sens tam, gdzie zasady często się zmieniają albo wymiana dostawcy jest zapowiedziana lub prawdopodobna. Nie opłaca się na przykład w słowniku kategorii produktów, w panelu do poprawiania opisów i zdjęć albo w ustawieniach. Poza „nazwa jest wymagana” nie ma tam zasad do ochrony, a dodatkowe gniazdko oznaczałoby tylko, że każde nowe pole trzeba dopisywać w kilku miejscach.

Podobnie jest w małym sklepie z jednym operatorem płatności i prostymi zasadami, którego nikt nie planuje rozbudowywać. Nie opłaca się też budować gniazdek na zapas, „na wypadek, gdybyśmy kiedyś zmienili bazę”. Granica ustalona bez wiedzy o przyszłym zamienniku i tak zwykle wymaga przeróbki, kiedy on się pojawi.

Dla działu IT: to podejście nazywa się portami i adapterami (architektura heksagonalna), a gniazdko i przejściówka to właśnie port i adapter. Autor tej nazwy, Alistair Cockburn, opisał ją w artykule Hexagonal architecture (po angielsku).