Architektonické inspirace a převzaté koncepty

Cílem není kopírovat konkrétní framework nebo databázový model. Cílem je převzít ověřené koncepty z moderních e-commerce systémů a přizpůsobit je vlastnímu provozu, importům, SEO, skladům a workflow.

Používáme:

  • Vendure pro katalogovou a content architekturu
  • Medusa pro pricing a inventory model
  • Sylius hlavně pro Option vs Attribute
  • Spree jako inspiraci pro REST API a některé e-commerce patterny
  • Meilisearch jako search engine a indexační vrstvu

Nejde o vendor-lock. Model je navržen jako vlastní PostgreSQL-first architektura bez ORM závislosti.

Vendure — převzaté koncepty

Vendure je hlavní inspirace pro katalogovou vrstvu.

Product vs Variant

Vendure: - Product = katalogová entita - ProductVariant = prodejná jednotka

Převzato:

  • product
  • product_variant

Produkt: - SEO - obsah - kategorizace - merchandising

Varianta: - SKU - EAN - sklad - cena - fyzická položka

Translation layer

Vendure používá oddělené translation tabulky.

Převzato:

  • product_translation
  • brand_translation
  • category_translation
  • collection_translation

Výhody: - žádné sloupce typu name_sk - čisté lokalizace - snadné přidání nového jazyka

Fallback řeší aplikace, ne databáze.

Collection koncept

Vendure: - Collections jako kurátorované nebo dynamické skupiny produktů

Převzato:

  • collection
  • collection_product

Použití: - homepage - slider - landing pages - seasonal akce - merchandising

Search document

Vendure používá: - denormalizovaný search index

Převzato:

  • product_search_document
  • product_search_dirty

Důvod: - search nesmí dělat těžké JOINy - search engine dostává hotový dokument

Medusa — převzaté koncepty

Medusa je hlavní inspirace pro pricing a inventory.

Price set model

Medusa: - varianta nemá jednu cenu - má kontejner cen

Převzato:

  • price_set
  • price

Výhody: - regionální ceny - quantity pricing - akce - časová platnost - více typů cen

Výrazně lepší než: - price_a - price_b - price_c

Inventory model

Medusa: - oddělení fyzického stocku od obchodní dostupnosti

Převzato:

  • inventory_item
  • inventory_level
  • supplier_availability
  • availability_text
  • inventory_reservation

Důležité: - fyzický stock != text pro zákazníka - rezervace != sklad - supplier stock != vlastní sklad

Reservation model

Medusa používá: - explicitní reservation records

Převzato:

  • inventory_reservation

Zdroj pravdy: - reservation tabulka

Optimalizace: - reserved_quantity jako cache

Multi-location inventory

Medusa: - stock per location

Převzato:

  • stock_location
  • inventory_level

Výhody: - centrála - externí sklady - pickup pointy - budoucí expanze

Sylius — převzaté koncepty

Ze Sylius zůstává hlavně jeden velmi důležitý koncept.

Option vs Attribute

Převzato:

  • option_group
  • option_value
  • attribute
  • product_attribute_value

Rozdělení:

Option: - tvoří variantu/SKU - velikost - barva

Attribute: - pouze popisná vlastnost - materiál - výkon - váha

Tím se řeší historický chaos: - varianty - barvy - parametry - technické údaje

Co ze Sylius nepřebíráme

Nepřebíráme: - Doctrine-heavy architekturu - entity graph model - plugin ecosystem - ORM-first přístup

Architektura je: - SQL-first - PostgreSQL-first - bez ORM závislosti

Spree — převzaté koncepty

Spree je inspirace hlavně pro REST API přístup a některé e-commerce patterny.

REST API styl

API bude: - resource-oriented - predictable - explicitní - bez magických ORM response struktur

Inspirace: - Spree API - Stripe API - Medusa API styl

Například:

  • /products
  • /products/{id}
  • /products/{id}/variants
  • /collections
  • /categories
  • /cart
  • /orders

Oddělení katalogu a objednávek

Spree historicky dobře odděluje: - katalog - checkout - order processing

Tento princip zůstává zachován.

Promotion patterny

Spree: - promotions jako samostatná pravidla

Převzato:

  • promotion
  • promotion_product
  • promotion_brand
  • promotion_category

Meilisearch — search architektura

Meilisearch není zdroj pravdy.

Zdroj pravdy: - PostgreSQL

Meilisearch: - pouze index a search engine

Search dokument

Search engine dostává: - denormalizovaný dokument

Převzato:

  • product_search_document

Obsahuje: - text - cenu - sklad - facety - kategorii - značku - SEO data

Bez JOINů při search query.

Async indexing

Search sync je asynchronní.

Převzato:

  • product_search_dirty

Trigger: - pouze označí dirty stav

Worker: - rebuildne dokument - odešle do Meilisearch

Facety

Facety nevznikají samostatnou DB vrstvou.

Generují se: - z product_attribute_value - při tvorbě search dokumentu

Tím: - databáze zůstává jednodušší - search engine dostává hotové facety

Celková architektonická filozofie

Architektura je:

  • PostgreSQL-first
  • SQL-first
  • bez ORM závislosti
  • explicitní
  • auditovatelná
  • import-friendly
  • search-first
  • async-first

Databáze není jen úložiště.

Databáze řeší: - konzistenci - inventory - pricing - strom kategorií - constrainty - audit - procedury - snapshoty

Aplikace řeší: - orchestrace - workflow - API - UI - integrace - search sync - business procesy

Co záměrně NEkopírujeme

Záměrně nepřebíráme:

  • ORM-heavy architektury
  • ActiveRecord styl
  • magické entity graphy
  • plugin spaghetti
  • framework coupling
  • business logiku schovanou v ORM

Cíl: - jednoduché SQL - čitelný model - kontrola nad query - vysoká auditovatelnost - dlouhodobě udržitelná architektura