Domů/Zdroje/Architektura
Architektura7 min čtení

Kdy psát Apex — a kdy to nechat být.

Rozhodovací rámec pro Salesforce týmy, které volí mezi konfigurací, Flow, Apexem, LWC a externími službami.

Klíčové poznatky
  • Pro jednoduchá a transparentní byznysová pravidla používejte konfiguraci.
  • Apex nasaďte tam, kde to vyžaduje složitost, řízení transakcí nebo testovatelnost.
  • Nechte to být, když Salesforce není správným prostředím pro běh dané logiky.

Špatná otázka zní „umí to Salesforce?“

Lepší otázka je, zda má danou logiku vlastnit právě Salesforce. Pravidlo, které je viditelné pro zákazníky, auditovatelné a blízko CRM datům, do Salesforce patřit může. Výpočetně náročné úlohy, transformace dat nebo dlouhotrvající integrace patří spíš jinam.

Kdy vítězí konfigurace

Konfigurace je nejlepší tam, kde je logika přímočará, vlastněná byznysem a snadno dohledatelná. Validace, průvodcovské obrazovky, základní routing a standardní schvalování se nemají měnit v kód jen proto, že je zrovna po ruce vývojář.

Kdy je Apex bezpečnější volba

Apex je na místě, když pravidla vyžadují transakční hranice, hromadné zpracování, spolehlivé testy, znovupoužitelné doménové služby nebo řízené ošetření chyb. Složitý kód pro revenue, orchestraci a integrace je často bezpečnější jako Apex než jako bludiště flow.

Kdy to nechat být

Některé požadavky jsou signálem sáhnout po externí službě: náročné zpracování dokumentů, rozsáhlé dávkové transformace, komplexní vyhledávání, event streaming nebo logika sdílená napříč více systémy. K dobré architektuře patří i umět platformě říct ne, když není tím správným nástrojem.

Potřebujete tohle ve svém orgu?

Svěřte tu těžkou část seniornímu Salesforce engineering týmu.

Probrat tento pattern s týmem, který ho staví