Guardrails a zákazy¶
Tato stránka je záměrně praktická. Má sloužit jako rychlá kontrola při návrhu změn.
Co se smí¶
- rozdělovat odpovědnost podle domén,
- držet produkt jako katalogovou kotvu,
- navazovat cenu a sklad primárně na variantu,
- používat translation tabulky místo jazykových sloupců,
- budovat search jako denormalizovaný read model,
- přesouvat kritická pravidla do DB procedur a triggerů, pokud hlídají konzistenci.
Co se nesmí¶
- vracet se k modelu "jedna tabulka na všechno",
- ukládat cenu přímo do produktu,
- ukládat fyzický sklad přímo do produktu,
- míchat zákaznický text dostupnosti s interním stockem,
- zapisovat přímo do
content.category_closure, - obcházet
pricing.price_upsert()přímými zápisy, - používat Meilisearch jako zdroj pravdy,
- nechat import přepisovat editoriální obsah bez explicitního pravidla,
- tvořit nové vazby jen proto, že je to rychlé, bez jasné doménové odpovědnosti.
Typické varovné signály špatného návrhu¶
- "přidáme to jako další sloupec do product"
- "admin si to zapíše rovnou do DB, bude to jednodušší"
- "frontend si to nějak dojoinuje sám"
- "search bude vracet všechno, tak už nic dalšího nepotřebujeme"
- "rezervace budeme držet jen jako číslo"
- "lokalizace se doplní později"
Pokud návrh zní takto, je velmi pravděpodobné, že míří zpátky do starého chaosu.
Kontrolní otázky před návrhem¶
- Do jaké domény ta změna skutečně patří?
- Kde bude zdroj pravdy?
- Kdo smí tato data měnit?
- Je to write model, nebo read model?
- Není to jen zkratka, která rozbije hranice systému?
- Nevzniká tím vazba, která bude bolet při importu, lokalizaci nebo indexaci?
Praktické rozhodovací pravidlo¶
Když si nejsme jistí, jestli něco přidat do product, je správná výchozí otázka:
Není to spíš pricing, inventory, content, search nebo system concern?
Ve většině případů bude odpověď ano.