Įrodymai, ne pažadai
Inžineriniai įrodymai svarbiausiems teiginiams.
Galingas, lankstus ir greitas yra pigūs žodžiai. Čia PerkRule aiškina architektūrą, ribas ir kompromisus už produkto.
ĮRODYMAS 01 / NATYVI NUOSAVYBĖ
Kodėl PerkRule nepakeičia WooCommerce kuponų.
WooCommerce jau turi kuponų modelį, duomenų sluoksnius ir ekosistemos lūkesčius. PerkRule palieka WC_Coupon pagrindu ir prideda tik tas akcijų sąvokas, kurių WooCommerce natūraliai neturi.
AUTORITETO RIBA
WooCommerce lieka autoritetu kuponams, krepšeliams, užsakymams ir natyviai nuolaidų matematikai.
PerkRule nekuria atskiros kuponų lentelės ir nedubliuoja laukų, kuriuos WooCommerce jau valdo. Natyvus aprašymas, publish/draft būsena, galiojimas, apribojimai ir piniginis skaičiavimas lieka WooCommerce būsena. PerkRule metaduomenys skirti tik papildomoms akcijų sąvokoms. Tai reiškia, kad įprastas WooCommerce CRUD ir ekosistemos lūkesčiai lieka prasmingi net be PerkRule.
PERSISTENCE DISCIPLINA
Natyvūs duomenys keičiasi per WC_Coupon CRUD, o PerkRule konfigūracija lieka aiškiai namespaced.
Repository normalizuoja kodus per WooCommerce, naudoja WC_Coupon setterius ir save operacijas, o collision ar nepavykęs rollback yra tikra persistence klaida, ne neaiškus false/null rezultatas. Sudėtingesnės PerkRule definicijos saugomos skaidriu versijuojamu JSON, ne PHP serializacija. Aiški persistence riba padeda rollback, migracijoms, HPOS ir integracijoms būti patikrinamiems, o ne magiškiems.
ĮRODYMAS 02 / CHECKOUT SAUGUMAS
Kas draudžiama gyvame krepšelio vertinime.
Licencijos užklausos, atnaujinimai, telemetrija, migracijos, DDL, CSV darbai ir pilni kuponų skenavimai nepriklauso checkout karštajam keliui. Akcijų sprendimai turi likti lokalūs ir riboti.
HOT-PATH TAISYKLĖ
Checkout nėra vieta schemų remontui, licencijos užklausoms ar administraciniams darbams.
Gyvame krepšelio vertinime nėra nuotolinio licencijavimo, update tikrinimo, telemetrijos siuntimo, migracijų, DDL, CSV darbų, visų kuponų skenavimo ar pirkimų istorijos užklausų. Nuo custom schemos priklausomi servisai startuoja tik tada, kai ribotas schemos versijos snapshot tiksliai sutampa su kodo lūkesčiu. Jei schema pasenusi, tie servisai tiesiog nedalyvauja, o WooCommerce toliau veikia.
RIBOTAS DARBAS
Teisingumas derinamas su aiškiomis ribomis, kad viena akcija tyliai netaptų neribotu checkout darbu.
Taisyklių dokumentai turi dydžio, gylio ir node skaičiaus limitus. Kandidatų paieška turi kietą talpą. Cache raktai ir identifikatoriai ribojami. Konfliktų sprendimas deterministinis, o ne kombinatorinis, o Best Deal vertina tik ginčijamus kandidatus aiškiose grupėse. Šios ribos yra architektūros dalis, nes cart ir checkout lifecycle tą patį kodą gali iškviesti daug kartų.
ĮRODYMAS 03 / AUTO APPLY
Automatinis nereiškia nekontroliuojamas.
Auto Apply naudoja tą patį validavimo kelią kaip rankiniai kuponai, keičia krepšelį per viešas WooCommerce API ir seka nuosavybę, kad PerkRule nepašalintų kupono, kurį klientas pritaikė pats.
VALIDUOTI PRIEŠ KEIČIANT
Auto Apply naudoja tą pačią tinkamumo logiką, o ne antrą, laisvesnį kelią.
Kiekvienas automatinis kandidatas eina per PerkRule kupono validavimo servisą, kuris išsaugo natyvų WooCommerce sprendimą ir vertina subject kuponą immutable kontekste, iš kurio tas pats kuponas pašalintas iš applied-coupon sąrašo. Taip kuponas negali netyčia patenkinti taisyklės pats savimi. Iki mutacijos prieina tik tie kandidatai, kurie praėjo native validumą, PerkRule taisykles ir policy resolution.
NUOSAVYBĖS PROVENANCE
Runtime seka sėkmingus automatinius pakeitimus, o ne vien kuponus su Auto Apply nustatymu.
Šis skirtumas saugo kliento veiksmus. PerkRule gali pašalinti pasenusį kuponą tik turėdamas aiškų session provenance, kad jį pritaikė pats. Pašalinimas nuosavybę išvalo, todėl vėlesnis rankinis pritaikymas negali paveldėti senos automatinės nuosavybės. Rankiniai ir nesusiję kuponai lieka apsaugotos sąlygos net tada, kai individual-use ar exclusivity trukdo automatiniam kandidatui.
ĮRODYMAS 04 / STACKING
Kodėl konfliktai sprendžiami prieš pakeitimus.
Prioritetas, išskirtinumas, konfliktų grupės ir Best Deal pirmiausia suplanuojami. Deterministinis planas sumažina nuo vykdymo eilės priklausantį elgesį ir daro gedimus suprantamesnius.
DETERMINISTINĖ TVARKA
Ta pati tinkamų kandidatų būsena turi duoti tą patį planą nepriklausomai nuo atsitiktinės iteravimo eilės.
Phase 09 kandidatus rikiuoja pagal Best Deal score ten, kur jo reikia, tada pagal prioritetą ir galiausiai stabilų kupono ID tie-breaker. Stack, exclusive, conflict-group ir Best Deal režimai aprašo santykį tarp akcijų nesusilpnindami natyvaus WooCommerce individual-use. Apsaugotas rankinis kuponas nėra išmetamas vien tam, kad automatinė akcija galėtų lengviau patenkinti savo politiką.
IZOLIUOTAS VERTINIMAS
Best Deal bandymai vyksta krepšelio kopijoje, o ne eksperimentuojant su pirkėjo gyva būsena.
Vertinami tik ginčijami Best Deal kandidatai. Scoreris klonuoja krepšelį ir line product objektus, prideda bendrą apsaugotų kuponų baseline bei vieną kandidatą ir leidžia natyviai WooCommerce totals logikai apskaičiuoti efektą. Jis nerašo session, nekuria notices ir nekviečia public live-cart calculate_totals bandymui. Jei score nepavyksta, reconciliation sustoja prieš tikrą mutaciją.
Pradėk nuo produkto, kurį aprašo šie užrašai.
Produktas 001 sujungia šias ribas į vieną WooCommerce akcijų variklį.
Peržiūrėti Produktą 001PerkRule pagalbos erdvė
Tikra pagalba veikia geriau, kai galima normaliai pasikalbėti.
PerkRule Discord bus tiesioginė vieta diegimo klausimams, klaidų pranešimams, suderinamumo pastaboms ir išleidimų aptarimui. Naudingi atsakymai neturi dingti privačiuose ticketuose — pasikartojančios problemos galės virsti dokumentacija ir Inžinerijos užrašais.
Discord atsidarys artėjant Produkto 001 išleidimui