A Netorigo okoszisztema — egy admin, 6 modul

Az „okoszisztema” szo annyira agyonhasznalt a SaaS-vilagban, hogy mar semmit nem jelent. Mi konkretumokkal valtottuk fel: a Netorigo okoszisztema az, ahol egy admin felulet (admin.netorigo.com) alol hat backend modul mukodik, mindegyik egy egyseges tenant-modellben. Az alabbi cikkben szetszedjuk, mi van valojaban a fedel alatt, es egy konkret rendelesi adatfolyam pelda is jon a vegere.

A hat modul

A hat modul nem hat micro-szolgaltatas a klasszikus ertelemben — nem egy „minden modul kulon repo, kulon adatbazis, kulon deploy” halmaz. Hanem hat funkcionalis hatarvonal egy kozos NestJS monorepoban, kulon-kulon adatbazisemarekkel:

1. Catalog — termekek, kategoriak, attribuumok, media, i18n forditasok. A products, product_translations, categories, tags tabla-csalad.
2. Sales — rendelesek, kosarak, ajanlatkeresek, kuponok. A sales_orders, cart_lines, quotes tabla-csalad.
3. Inventory — keszlet, raktarak, beerkezesek, foglalas. Az inventory_levels, warehouses, stock_movements tabla-csalad.
4. Finance — szamlazas, NAV bevallas, GL kontiroles. Az invoices, payments, gl_entries tabla-csalad.
5. Logistics — szallitas, raktari pick-pack, futar-API integraciok. A shipments, pick_lists, carrier_quotes tabla-csalad.
6. Travelium — utazasi termekek, foglalasok, allotment-kezeles. A travel_products, travel_bookings, allotments tabla-csalad — a klasszikus ERP-modulok mellett egy domain-specifikus extension.

A hatodik modul mar mutatja, hogy a Netorigo nem altalanos e-commerce platform, hanem egy domain-extensible ERP. Holnap egy 7. modul lehet Education (kurzusok, vizsgak) — ugyanazon admin alol, ugyanazon tenant-modellben.

Egy tenant, sok storefront

A tenant a kozos jogi szemely (peldaul „Netorigo Kft.”), aki a 6 modul mindegyiket hasznalhatja. Egy tenant alatt tobb storefront is futhat: netorigo.com, travelium.hu, nortinia.com, mediaorigo.hu es meg 9 testver. 13 storefront, egy tenant, hat backend modul — ez a mostani realitas.

A storefrontok az adminban CMS-szeruen szerkeszhetok: navigation menu, landing oldalak, kategoriak megjelenesi sorrendje, SEO landingok. De a termek-katalogus EGY van. Egy SKU egyszer letezik a Catalog modulban — hogy melyik storefronton bukkan fel, az csak egy storefront_visibility jelolo.

Adatfolyam: egy travelium foglalas vegigfut

Konkret pelda. A vasarlo travelium.hu-n megnyit egy „Barcelona 4 ej” termeket es lefoglalja:

1. Catalog: a termek-detail page lekeri a travel_products tablat (slug-alapjan), forditasokat (product_translations HU locale), keszlet-status placeholdert.
2. Inventory + Travelium: az allotmentre rakerdez (van-e szabad ferohely az aktualis datumon).
3. Sales: a vasarlo a kosarba teszi, megadja a foglalas adatait (utas-nev, datumok). A cart_lines egy travel_metadata JSONB-vel egeszul ki.
4. Checkout: ar-kalkulacio (Finance modul VAT-logikat), kupon-ellenorzes (Sales), kifizetes (payment provider integraciot Finance vegzi).
5. Sales → Inventory: a sales_orders.confirmed event allotment-foglalast trigger-el a Travelium modulban (travel_bookings insert).
6. Finance: a kozos invoice_generation queue letrehoz egy szamlat, NAV bevallasi rendszerbe submittal.
7. Logistics: ha az utazasi termek mellett gift_voucher van (PDF), a Logistics queue elkesziti es e-mailezi.
8. Travelium: 24 oraval az utazas elott a Travelium modul travel_reminders cron-ja kuld emlekezteto e-mailt.

Egyetlen ugyfel-action — egy foglalas — hat modult erintett, kozben egyetlen tenant, egyetlen admin felulet alol.

A kulcs: nincsenek silok

A klasszikus „ERP + e-commerce + booking-system” triashban harom kulonbozo szoftver, harom kulonbozo szerzodes, harom kulonbozo API integracio. A Netorigo-modellben egy szerzodes, egy admin, egy adatfolyam — es a 6. modul holnap a 7. lehet anelkul, hogy a klienst ujra a 0-rol felepiteni kellene. Ez az, amit valoban okoszisztemanak nevezunk.