Skip to content

Sylius — interní analýza pro výběr platformy

Pozice Syliusu na trhu

Sylius sedí přesně mezi dvěma světy: - Příliš velký na Shopify / WooCommerce — ty nestačí na katalog tohoto rozsahu - Příliš malý na enterprise řešení (SAP Commerce, Commercetools) — ta jsou zbytečně drahá a těžká

Pro PHP firmu se Symfony zázemím je Sylius přirozená volba. Onboarding je téměř nulový.

Co Sylius přinese hotové

  • Produktový katalog, košík, checkout, objednávky
  • Platby a dopravy jako rozšiřitelný model
  • Admin
  • State machine pro checkout/order flow

Kde Sylius nelze ohýbat — a co to znamená

Sylius má pevný model světa. Lze ho rozšiřovat, ale nelze přepisovat jeho základní koncepty bez toho, aby se projekt stal "přepisujeme Sylius".

Konkrétní příklady z tohoto projektu:

Cenotvorba — Sylius má ChannelPricing: jedna cena na kanál, hotovo. Současný systém má pipeline 5+ vrstev: Pohoda pošle cenu → přepíše ji dodavatelský import → přepíše ji skript výjimek výrobců → přepíše ji logika skladu Zlatnická → přepočítá SQL trigger. Tohle v Syliusu neexistuje jako koncept. Celá pipeline musí žít mimo Sylius a do ChannelPricing přijde už finální číslo.

Flag neprepsat — v současném systému existuje příznak na produktu: "import nesmí přepsat ručně upravená data". Používá ho všech 14 importů. Sylius nic takového nativně nemá. Musí být custom atribut + logika v importní vrstvě.

Varianty a barvy jako oddělené entity — v současném systému jsou barvy (eshop_produkty_barvy) a varianty (eshop_produkty_varianty) dvě různé věci, obě bez vlastní ceny a skladu. Sylius řeší oboje přes ProductOption → ProductVariant. Mapování je proveditelné, ale vyžaduje jasné rozhodnutí při návrhu.

Překlady inline v tabulce — eshop_produkty má 80+ sloupců, překlady 6 jazyků přímo v řádku (nazev_en, nazev_de...). Sylius používá Doctrine extensions pro překlady (samostatné tabulky). Import musí tuto transformaci zvládnout.

Skrývání produktů podle marže — business pravidlo "skryj produkt pokud nízká marže a není skladem" běží jako cron. V Syliusu to musí být event listener na import, nebo součást importní pipeline.

Klíčová myšlenka: Sylius ušetří práci, pokud se mu přizpůsobíme. Sylius přidá práci, pokud ho budeme ohýbat podle starého systému.

Importní vrstva — co bude třeba postavit mimo Sylius

Toto je největší část projektu. Současný kód je spletenec PHP skriptů bez rozhraní, transakcí ani testů. Nelze migrovat — musí se přepsat.

Co importní vrstva musí umět:

  • Stáhnout a parsovat data od 14 dodavatelů (každý jiný formát)
  • Zpracovat Pohoda XML (diff i full import)
  • Spustit cenovou pipeline a vyproduktovat finální cenu před zápisem do Syliusu
  • Respektovat flag "nepřepisovat ručně upravená data"
  • Zapsat do Syliusu přes jeho API nebo command bus — nikdy přímý SQL
  • Logovat průběh a chyby
  • Zvládnout výpadek bez ztráty dat (žádný TRUNCATE bez transakce)

Riziková mapa:

Oblast Riziko Konkrétní důvod
Importní pipeline (14 zdrojů) 🔴 Vysoké Každý dodavatel jiný formát, roky akumulovaných výjimek v kódu
Pohoda integrace 🔴 Vysoké Obousměrná vazba, vlastní číselné řady, diff i full import
Cenová pipeline 🔴 Vysoké 5+ vrstev přepisů, magické konstanty, výjimky výrobců a skladů
Flag neprepsat 🟡 Střední Musí být reimplementován v importní vrstvě
Produktový model / překlady 🟡 Střední 80+ sloupců → Sylius Translation model
Varianty + barvy 🟡 Střední Mapování na ProductOption je čisté, ale vyžaduje návrh
Sylius samotný 🟢 Nízké Standardní e-commerce, žádné exotické požadavky

Editace produktů — dvojí pravda

Toto je největší provozní otázka. Aktuálně existuje flag neprepsat — admin může ručně upravit popis/fotky a import to nepřepíše.

V Syliusu budou dvě možnosti:

Varianta A — Sylius admin jako editor Produkty se editují v Sylius adminu. Importní vrstva ví, která pole jsou "uzamčena" a nepřepisuje je. - ✅ Jeden systém pro editory - ⚠️ Importní vrstva musí být velmi přesná v tom, co přepisuje a co ne

Varianta B — vše řeší importy, Sylius admin jen pro objednávky Produktová data žijí mimo Sylius (importní vrstva / mezistupeň). Sylius dostává vždy kompletní data. - ✅ Sylius zůstane čistý, žádné custom pole neprepsat - ⚠️ Editoři musí upravovat data mimo Sylius admin — potřebuje vlastní UI nebo PIM

Bez rozhodnutí o tomto bodu nelze zpřesnit odhad. Varianta A je provozně přirozenější, Varianta B je architektonicky čistší.

Odhad rozsahu

Oblast Hodiny
Analýza a technický návrh 80–150 h
PoC — import, Pohoda, cenová pipeline 40–100 h
Importní vrstva (14 dodavatelů) 150–400 h
Pohoda integrace 100–250 h
Sylius — katalog, checkout, objednávky 250–500 h
Migrace dat, testování, výkon 100–300 h
Varianta Hodiny
Čistý projekt 700–1 000 h
Realisticky 1 000–1 500 h
Se skrytými výjimkami v importech 1 500–2 000 h

Doporučený postup

Fáze 1 — placená analýza a PoC (80–120 h) - Návrh importní vrstvy a cenové pipeline - PoC jednoho dodavatele end-to-end do Syliusu - PoC Pohoda integrace - Rozhodnutí: Varianta A nebo B pro editaci produktů - Výstup: architektura, zpřesněný odhad, seznam rizik

Bez Fáze 1 není možné závazně nacenit realizaci.