Modernizacja Comers, wieloorganizacyjnej platformy e-commerce, do architektury mikroserwisowej

Spis treści

Kontekst systemu
Dlaczego monolit był właściwą decyzją 10 lat temu
Dlaczego modernizacja jest dziś konieczna
Strategia transformacji
Postęp modernizacji
Stan obecny
Aktualny rezultat
Architecture showcase

Kontekst systemu

Projekt dotyczy modernizacji Comers, autorskiej platformy do zarządzania sprzedażą online dostępnej pod adresem comers.app, zaprojektowanej i rozwijanej nieprzerwanie przez nasz zespół przez około 10 lat.

System powstał jako wewnętrzna platforma operacyjna wspierająca sieć sklepów internetowych działających w wielu krajach Unii Europejskiej.

Comers pełni rolę centralnego systemu sprzedażowo-integracyjnego, który nadal jest aktywnie rozwijany. Oprócz klasycznych procesów sprzedażowych system obejmuje dziś także coraz wyraźniejsze granice modułowe, procesy tła oraz pierwsze obszary operacyjnego wsparcia AI. Platforma umożliwia:

integrację wielu sklepów internetowych,
integrację z marketplace’ami (np. Amazon, eBay),
zarządzanie pełnym cyklem życia zamówienia,
integracje z firmami kurierskimi i obsługę wysyłek,
zarządzanie stanami magazynowymi i gospodarką magazynową,
obsługę zwrotów,
obsługę procesów serwisowych i gwarancyjnych,
zarządzanie listingami produktowymi,
generowanie faktur,
raportowanie operacyjne i analitykę,
tłumaczenie i obsługę wątków wiadomości,
wsparcie operatorów przy przygotowywaniu odpowiedzi do klientów,
operacyjne użycie AI przez jawne kontrakty i narzędzia domenowe.

Comers jest zaprojektowany jako system wieloorganizacyjny. W ramach jednej instancji może działać wiele organizacji, z których każda posiada:

własne integracje sprzedażowe,
własną konfigurację operacyjną,
własną strukturę użytkowników i uprawnień.

W obrębie każdej organizacji użytkownicy funkcjonują w różnych rolach operacyjnych i poziomach dostępu.

Platforma automatycznie wysyła również e-maile transakcyjne i operacyjne do klientów oraz pracowników, pełniąc funkcję centralnego węzła komunikacyjnego.

Dlaczego monolit był właściwą decyzją 10 lat temu

W momencie projektowania systemu:

architektura mikroserwisowa nie była jeszcze operacyjnym standardem dla platform średniej skali,
infrastruktura orkiestracji kontenerów nie była powszechnie stosowana,
kluczowymi celami były szybkość dostarczenia oraz stabilność operacyjna,
zespół operacyjny potrzebował jednego, spójnego systemu do zarządzania procesami sprzedażowymi.

Zbudowanie modularnego monolitu było świadomą decyzją architektoniczną:

jeden artefakt wdrożeniowy,
wspólne środowisko uruchomieniowe,
jedna relacyjna baza danych,
uproszczony proces deploymentu,
pełna kontrola nad przepływami operacyjnymi.

Przez lata podejście to potwierdziło swoją skuteczność biznesową.

System nie był eksperymentem — był realnym narzędziem operacyjnym obsługującym sprzedaż i logistykę na dużą skalę.

Dlaczego modernizacja jest dziś konieczna

Po dekadzie rozwoju system osiągnął naturalny punkt przegięcia architektonicznego. Modernizacja nie jest już wyłącznie planem docelowym — część nowych granic, procesów tła, warstw API i mechanizmów AI działa już w aktywnym runtime platformy.

1. Rosnąca gęstość integracji

Platforma integruje się z:

sklepami internetowymi,
marketplace’ami,
firmami kurierskimi,
systemami fakturowymi,
mechanizmami komunikacji.

Z czasem logika integracyjna znacząco zagęściła się w kluczowych obszarach domenowych.

Sformalizowanie granic stało się konieczne, aby:

ograniczyć zakres wpływu zmian,
poprawić separację odpowiedzialności,
umożliwić niezależną ewolucję obszarów o wysokiej intensywności I/O.

2. Wspólne środowisko uruchomieniowe dla wielu kontekstów wykonania

System obsługuje:

interaktywne żądania HTTP,
operacje wsadowe,
skrypty cykliczne (cron),
przetwarzanie kolejek zadań.

Wszystkie te ścieżki wykonania korzystają z tego samego runtime’u aplikacji.

Model ten historycznie był operacyjnie efektywny, jednak obecnie ogranicza elastyczność i skalowalność.

3. Potrzeba wyraźnej granicy frontendowej

Pierwotnie system funkcjonował jako interfejs operacyjny renderowany po stronie serwera.

Obecne wymagania obejmują:

wprowadzenie warstwy SPA,
oddzielenie kontraktów frontendowych od modeli domenowych,
ustanowienie warstwy Backend-for-Frontend (BFF).

BFF traktowany jest jako kluczowy element architektury, a nie jedynie adapter HTTP.

Strategia transformacji

Modernizacja prowadzona jest przez ten sam zespół, który zaprojektował i rozwijał platformę przez ostatnią dekadę.

Podejście ma charakter ewolucyjny, a nie rewolucyjny.

Faza 1 – Formalizacja granic

oddzielenie orkiestracji od przejść stanów,
izolacja adapterów integracyjnych,
wprowadzenie jawnych kontraktów między warstwami.

Priorytetem jest klarowność strukturalna przed fizycznym wydzieleniem usług.

Faza 2 – Ekstrakcja domen o wysokiej intensywności I/O

Wybrane obszary domenowe zostaną wydzielone jako niezależne usługi.

Kolejność ekstrakcji opiera się na:

gęstości integracji,
złożoności orkiestracji,
ryzyku zmian i wpływie operacyjnym.

To początek przejścia w kierunku architektury mikroserwisowej.

Faza 3 – Wprowadzenie warstwy BFF

Przed pełną migracją do SPA:

istniejące endpointy JSON są formalizowane jako granice kontraktowe,
warstwa BFF przejmuje odpowiedzialność za kształtowanie odpowiedzi,
rozwój frontendowy zostaje odseparowany od wewnętrznej domeny.

Faza 4 – Transformacja do architektury mikroserwisowej

Docelowa architektura obejmuje:

niezależne usługi zorientowane domenowo,
dedykowane konteksty wykonawcze,
rozdzielenie przetwarzania wsadowego od interaktywnych przepływów,
możliwość niezależnego skalowania.

Transformacja prowadzona jest w warunkach produkcyjnych.

Faza 5 – Operacyjne wsparcie AI

Pierwotnie AI było traktowane jako długoterminowy kierunek rozwoju. Obecnie pierwsza operacyjna warstwa AI została już wdrożona w wybranych obszarach, przede wszystkim w komunikacji, tłumaczeniach, obsłudze odpowiedzi, narzędziach MCP oraz capability gateway.

AI będzie:

operować wyłącznie na jawnych kontraktach,
generować rekomendacje i podsumowania,
wspierać decyzje operacyjne,
pełnić rolę warstwy wspomagającej, a nie niekontrolowanego obejścia logiki systemu.

Kluczowe decyzje architektoniczne

Modernizacja w trakcie aktywnej pracy systemu produkcyjnego.
Ciągłość operacyjna ważniejsza niż szybka, radykalna refaktoryzacja.
Najpierw definiowanie granic, dopiero później izolacja runtime’u.
Kolejność ekstrakcji oparta na gęstości integracji, a nie strukturze folderów.
Wczesne ustanowienie kontraktów przed separacją na poziomie usług.

Postęp modernizacji (realne zmiany)

Modernizacja nie ogranicza się do planów i kierunku architektonicznego —
kluczowe elementy transformacji zostały już wdrożone i działają w aktywnym runtime systemu.

W ramach dotychczasowych prac:

zbudowano nowe moduły domenowe (ebay, messages, listings, shipping, notifications),
przebudowano integrację eBay (Trading API + REST API) z użyciem portów i adapterów,
wprowadzono model komunikacji oparty o wątki wiadomości i dedykowany interfejs,
wydzielono moduł listingów z własnym API oraz pipeline’em ingestii danych,
uporządkowano integracje kurierskie (DPD, DHL) w ramach wspólnej warstwy shipping,
wdrożono moduł notyfikacji z własnym API i UI,
wprowadzono jawne kontrakty (porty) i adaptery w kluczowych obszarach systemu,
zastosowano model raw-first ingestion z możliwością reprocessingu danych,
przeniesiono artefakty (np. etykiety) do object storage (model stateless),
ustabilizowano runtime jobów (locki DB, timeouty, kontrola współbieżności),
uporządkowano środowisko uruchomieniowe i konfigurację (env-based),
wprowadzono pipeline’y CI/CD oraz przygotowanie pod konteneryzację,
odświeżono wybrane obszary interfejsu użytkownika.

Najnowszy etap: granice kontraktowe, AI i runtime

W kolejnej fazie modernizacja wyszła poza samo porządkowanie wybranych modułów wewnątrz monolitu. System zaczął ewoluować w kierunku architektury kontraktowej, w której starsza aplikacja, wewnętrzne API, warstwa Core API, narzędzia AI, gateway oraz procesy tła mają coraz wyraźniejsze odpowiedzialności.

Najważniejsze nowe obszary prac obejmują:

wydzielenie obszaru activities za pomocą API activities/v1, modelu odczytu i projekcji activities_current,
przejście historii aktywności w kierunku append-only audit logu, bez klasycznych aktualizacji i usuwania rekordów,
utworzenie nowego boundary orders dla synchronizacji zamówień zewnętrznych, danych eBay Fulfillment, terminów wysyłki i odczytu przez Core API oraz MCP,
rozbudowę modułu messages o tłumaczenia wątków i list wątków, preferencję języka użytkownika, workera tłumaczeń oraz wsparcie AI przy sugerowaniu i komponowaniu odpowiedzi,
rozszerzenie istniejącego modułu notifications o fasadę Core API i narzędzia MCP działające w kontekście konkretnego użytkownika,
wdrożenie pierwszej warstwy operacyjnej AI z osobnymi repozytoriami dla webapp, BFF, ChatKit runtime, MCP oraz AI gateway,
wprowadzenie comers-ai-gateway jako wewnętrznej warstwy capability dla translate.v1 i compose_reply.v1,
przeniesienie definicji runtime do osobnych repozytoriów infrastrukturalnych comers-infra-ai i comers-infra-legacy.

W praktyce oznacza to, że Comers nie jest już tylko modernizowanym monolitem z kilkoma nowymi modułami. To aktywnie rozwijana platforma operacyjna, w której nowe funkcje i nowe typy konsumentów są podłączane przez jawne kontrakty, a nie przez bezpośredni dostęp do starszej logiki aplikacji.

Ten etap oznacza również zmianę technologiczną całej platformy. Legacy pozostaje oparte o PHP/Yii2, natomiast nowe usługi backendowe i przyszłe mikroserwisy domenowe są projektowane głównie w stacku Node.js / TypeScript / NestJS / Fastify. Dotyczy to zarówno elementów core systemu, takich jak comers-core-api, jak i warstw wspierających nowe typy konsumentów, takich jak BFF, MCP czy gateway. Ten sam kierunek technologiczny jest przewidziany dla planowanych ekstrakcji domen, między innymi orders i messages.

Warstwa frontendowa jest rozwijana dwutorowo. Główne SPA pozostaje kierunkiem opartym o Angular, natomiast wybrane micro-frontendy mogą być budowane w React/Vite. Obecnym przykładem takiego micro-frontendu jest interfejs czatu AI. Równolegle wyspecjalizowane elementy runtime mogą korzystać z osobnych technologii, jeżeli lepiej pasuje to do ich roli — przykładem jest Python użyty dla backendowego runtime ChatKit.

Realne możliwości warstwy AI w obecnym etapie

W ostatnim etapie warstwa AI przestała być wyłącznie kierunkiem rozwoju. W systemie działa już asystent operacyjny, który korzysta z jawnych kontraktów i kontrolowanych narzędzi domenowych.

Asystent potrafi odpowiadać na pytania dotyczące realnych danych z systemu oraz wykonywać wybrane akcje. Może czytać listy i szczegóły wiadomości klientów, notyfikacje, informacje o zamówieniach oraz activity log. Może również oznaczać wiadomości i notyfikacje jako przeczytane oraz przenosić je do archiwum.

Szczególnie ważny jest rozwój modułu wiadomości. Comers wspiera tłumaczenie wątków, tytułów i list konwersacji na wybrany język, zapamiętuje preferencję językową użytkownika oraz uruchamia tłumaczenia w tle. AI potrafi zaproponować odpowiedź dla klienta na podstawie kontekstu rozmowy, a także poprawić, uporządkować i przetłumaczyć draft przygotowany przez operatora na docelowy język klienta.

Te funkcje nie zostały dodane jako luźna integracja z modelem AI. Są osadzone w architekturze przez comers-ai-webapp, comers-ai-bff, comers-ai-chatkit, comers-ai-mcp, comers-core-api i comers-ai-gateway. Dzięki temu AI działa przez API, narzędzia i capability contracts, a nie przez bezpośredni dostęp do modeli legacy.

Gotowość wybranych modułów do wydzielenia

Coraz więcej obszarów systemu ma już własne granice, kontrakty, API, read modele, porty, adaptery i osobne procesy runtime. Dotyczy to szczególnie messages, activities, orders, notifications, shipping oraz integracji marketplace.

To oznacza, że modernizacja nie polega już tylko na porządkowaniu kodu wewnątrz monolitu. Wybrane moduły są coraz bliżej technicznej gotowości do wydzielenia do osobnych usług, ponieważ nowi konsumenci systemu mogą korzystać z jawnych kontraktów zamiast z wewnętrznych modeli legacy.

Wybrane widoki platformy Comers

Zrzuty UI z Comers (comers.app) prezentowane są z anonimizowanymi danymi; ewentualny widoczny branding ograniczono do tożsamości produktu Comers.

Pełny, techniczny opis zmian:

👉 Log ewolucji architektury i modernizacji

Stan obecny

System pozostaje w pełni operacyjny i jest nadal rozwijany. Obecny stan to etap przejściowy między modularnym monolitem, architekturą kontraktową i pierwszymi wydzielonymi runtime’ami wspierającymi nowe funkcje.

Modernizacja ma charakter przyrostowy:

granice są formalizowane,
kontrakty są wzmacniane,
rozwijane są nowe moduły o wyraźnych boundary,
przygotowywani są kolejni kandydaci do wydzielenia,
nowe warstwy, takie jak Core API, MCP, BFF i AI gateway, są rozwijane jako kontrolowane punkty dostępu do domen systemu.

Część kluczowych elementów transformacji została już wdrożona i opisana w sekcji powyżej.

Aktualny rezultat

Projekt pokazuje:

odpowiedzialną modernizację systemu produkcyjnego,
ewolucję architektury bez zakłóceń operacyjnych,
długoterminowe myślenie systemowe oparte na ciągłości domenowej.

To nie jest greenfield ani przepisanie systemu od zera.

To produkcyjnie sprawdzona platforma operacyjna, Comers (comers.app), transformowana w sposób kontrolowany, kontraktowy, przez zespół, który ją zaprojektował i utrzymywał od samego początku.

Architecture showcase (GitHub)

To case study opisuje kontekst, ewolucję i strategię transformacji systemu.

Jeśli chcesz zobaczyć:

jak dziś zorganizowany jest modularny monolit,
które granice zostały zidentyfikowane i sformalizowane,
jak sekwencjonowana jest ekstrakcja domen w kierunku mikroserwisów,
jakie decyzje architektoniczne i kompromisy prowadzą transformację,

przygotowaliśmy dedykowane architecture showcase.

Repozytorium zawiera:

opis architektury runtime i kontekstów wykonawczych,
mapowanie modułów i integracji,
model modernizacji krok po kroku,
analizę granic domenowych,
operacyjne i ewolucyjne założenia projektowe,

bez ujawniania logiki biznesowej ani wrażliwych danych.

👉 Architecture showcase (GitHub)
https://github.com/rocketdeploy-dev/showcase-commerce-platform-modernization