Enterprise SaaS w Railsie nie zaczyna się od mikroserwisów

Enterprise SaaS nie zaczyna się od mikroserwisów, Kubernetesa ani kilkunastu repozytoriów. Zaczyna się od granic odpowiedzialności, izolacji organizacji, konsekwentnej autoryzacji i historii, której można zaufać.

Rails dobrze pasuje do tego zadania. Jego prostota pozwala trzymać decyzje biznesowe blisko kodu, ale nie zwalnia z dyscypliny. Gdy aplikacja obsługuje wiele organizacji, role, procesy w tle i krytyczne decyzje, sama konwencja frameworka przestaje być architekturą.

Najpierw właściwe granice

Modularny monolit daje jeden proces wdrożeniowy i jedną transakcję bazy, a jednocześnie pozwala oddzielić stabilną platformę od zmiennej domeny.

Platforma może współdzielić:

• identity i authentication,
• organizacje, członkostwa i role,
• pliki i bezpieczny dostęp,
• audit log,
• kontekst requestów i jobów,
• wspólne zasady prywatności.

Moduł biznesowy zachowuje własne modele, komendy, polityki, zdarzenia oraz reguły procesu. Dzięki temu kolejny moduł korzysta z dojrzałych mechanizmów platformy, ale nie musi udawać, że jego workflow ma takie samo znaczenie jak proces istniejący dzisiaj.

Kontekst jest częścią operacji

Każda krytyczna komenda powinna znać nie tylko rekord, który zmienia. Potrzebuje również aktora, organizacji, roli oraz źródła wywołania. Ten sam przypadek użycia może przecież zostać uruchomiony przez kontroler, job, import albo narzędzie administracyjne.

Request / Job
      ↓
Actor + Organization + Role
      ↓
Policy + Business Command
      ↓
Business State + Audit Event
      ↓
One PostgreSQL Transaction

Kontroler obsługuje HTTP, policy chroni endpoint i zakres zapytania, a komenda pilnuje niezmienników przypadku użycia. Ukrycie przycisku jest dobrym UX, lecz nie jest granicą bezpieczeństwa.

Audyt jest elementem transakcji

W krytycznej operacji zmiana stanu i odpowiadające jej zdarzenie audytowe powinny zostać zapisane razem. Jeżeli audytu nie da się utrwalić, zmiana biznesowa również nie powinna zostać zatwierdzona.

Zdarzenie potrzebuje stabilnego typu, publicznego identyfikatora, aktora, organizacji, źródła oraz korelacji z requestem albo jobem. Metadane powinny być ograniczone kontraktem: bez haseł, tokenów, dokumentów czy całych parametrów żądania.

Ochrona wyłącznie w modelu Rails nie wystarcza. Proces aplikacji nie powinien być właścicielem tabel audytowych ani superuserem bazy. Runtime może dopisywać zdarzenia, ale nie powinien móc ich zmieniać, usuwać ani wyłączać zabezpieczeń.

DRY oznacza wspólne znaczenie

Dwa fragmenty kodu nie tworzą dobrej abstrakcji tylko dlatego, że wyglądają podobnie. Warto współdzielić stabilny mechanizm - nagrywanie zdarzeń, sprawdzanie członkostwa, propagowanie correlation ID - nie różne decyzje biznesowe ubrane w jeden uniwersalny silnik.

KISS również nie oznacza “najmniej klas”. Oznacza najprostszy projekt, który zachowuje wymagane gwarancje i pozostaje czytelny dla następnego zespołu.

Co naprawdę daje enterprise foundation

Kod może zapewnić izolację tenantów, integralność zdarzeń, kontrolę dostępu i obserwowalność. Nie zapewnia automatycznie compliance. Do tego potrzebne są polityki retencji, procedury awaryjne, testy odtwarzania, rotacja poświadczeń i czasem zewnętrzna granica zaufania.

Rails nadal świetnie nadaje się do poważnych systemów SaaS. Największą przewagą modularnego monolitu nie jest brak mikroserwisów. Jest nią możliwość utrzymania reguł biznesowych, transakcji i odpowiedzialności w jednym zrozumiałym miejscu.

Zobacz także nasze podejście do technologii i standardów produkcyjnych oraz modernizacji i stabilizacji systemów. Jeśli porządkujesz podobny system, zacznij rozmowę.