Państwa procesy zasługują na odpowiednie oprogramowanie.

Reguły biznesowe, transakcje i współbieżne zmiany

Aplikacja musi działać prawidłowo również wtedy, gdy kilka osób jednocześnie zmienia ten sam stan magazynowy. Dwie rezerwacje nie mogą niezauważenie przydzielić tej samej, ostatniej sztuki towaru. Dlatego określamy, które zmiany muszą zakończyć się sukcesem razem, a które konflikty wymagają komunikatu dla użytkownika na poziomie biznesowym. Ograniczenia bazy danych, transakcje i sprawdzanie wersji mogą rozwiązywać różne części tego zadania; sam interfejs nie zabezpieczy tych reguł.

Dłuższe procesy biznesowe natomiast często nie mieszczą się w jednej transakcji. Zamówienie, zewnętrzna usługa płatnicza i zatwierdzenie wysyłki mają własne stany błędów. Proces modelujemy za pomocą przejrzystych stanów i dopuszczalnych przejść między nimi. Ponawiane żądania otrzymują odpowiedni identyfikator operacji, aby zerwanie połączenia nie wywoływało automatycznie podwójnej akcji. W przypadku błędów częściowych potrzebna jest korekta zdefiniowana merytorycznie, na przykład wycofanie zatwierdzenia, a nie ogólny techniczny restart.

Dzierżawcy, role i dostęp do danych możliwy do prześledzenia

Dla produktów SaaS i platform wewnętrznych odróżniamy tożsamość użytkownika od jego uprawnień do konkretnego rekordu. Zalogowany pracownik nie ma automatycznie prawa do odczytu każdej faktury czy każdego zlecenia. Dostępy sprawdzamy w backendzie na poziomie organizacji, roli i operacji. Te granice muszą uwzględniać również eksporty, indeksy wyszukiwania, zadania w tle i zapisane w pamięci podręcznej wyniki.

Wspólne tabele z oznaczeniem dzierżawcy, rozdzielone schematy baz danych lub własne bazy danych niosą ze sobą różne wymagania dotyczące izolacji, migracji i odtwarzania. Model wybieramy na podstawie wymaganego poziomu rozdzielenia i sposobu organizacji eksploatacji u Państwa. Testy z wieloma dzierżawcami sprawdzają w szczególności niedozwolone dostępy. Rejestr audytowy dokumentuje istotne merytorycznie zmiany z odpowiednim kontekstem; jakie dane się w nim znajdują i jak długo są dostępne, ustalamy w sposób jednoznaczny.

Przechowywanie danych, wydajność i długoterminowa rozszerzalność

Struktura danych wynika z zapytań i reguł biznesowych. Analizujemy typowe filtry, sortowania, raporty i operacje zapisu, zanim wprowadzimy dodatkowe technologie przechowywania danych. Nieograniczone listy wyników, powtarzane pojedyncze zapytania i duże transfery danych mogą spowolnić aplikację, choć serwer wydaje się niemal nieobciążony. Pomiary z realistycznymi ilościami danych pokazują, czy pomagają indeksy, zmiany zapytań, paginacja lub inny podział zadań.

Buforowanie (caching) jest świadomą decyzją dotyczącą aktualności danych: musi być jasne, kiedy zapisany wynik traci ważność i którzy użytkownicy mogą go zobaczyć. Obszerne obliczenia mogą działać jako zadania w tle, wymagają jednak wskaźnika postępu, możliwości ponownego uruchomienia i stanów błędów. Przy rozszerzeniach oddzielamy reguły biznesowe od technicznych adapterów. Automatyczne testy i wersjonowane zmiany bazy danych zabezpieczają te granice, dzięki czemu nowy kanał lub inny dostawca nie wymusza zmian w każdym module.