CMS satura modelis: kā projektēt laukus, statusus un datu attiecības, lai sistēma būtu pārvaldāma arī pēc gada

Pārvaldāma CMS satura modeļa izveide sākas ar skaidru vienošanos par satura objektiem, to nozīmi, dzīves ciklu un savstarpējām attiecībām. Katram laukam vajag vienu saprotamu uzdevumu, katram statusam — atļautas pārejas, bet katrai relācijai — kardinalitātes, īpašnieka un dzēšanas noteikumus. Pirms izstrādes jāizveido modeļa katalogs, tas jāpārbauda ar reāliem satura piemēriem un jāparedz shēmas izmaiņu process. Šāda pieeja nepadara modeli nemainīgu; tā ļauj to mainīt kontrolēti, nezaudējot datu nozīmi un nesalaužot integrācijas.

Kas ir CMS satura modelis

CMS satura modelis ir formāls apraksts tam, kādus satura objektus sistēma glabā, kādi dati raksturo katru objektu, kā tas maina stāvokli un kā tas ir saistīts ar citiem objektiem. Satura tips “Raksts” redaktoram parādās kā forma, bet sistēmā tas ir noteikumu kopums, kuru izmanto administrācijas saskarne, publiskā mājaslapa, meklēšana, API, importi un citas integrācijas.

Modelī jānošķir vismaz četri elementi:

•          entītija — patstāvīgs objekts ar identitāti, piemēram, raksts, autors vai pakalpojums;
•          lauks — viena objekta īpašība, piemēram, virsraksts, publicēšanas datums vai cena;
•          statuss — objekta vieta noteiktā darba vai publicēšanas procesā;
•          attiecība — strukturēta saite starp objektiem, piemēram, rakstam ir autors.

Modelis noveco slikti, ja šie jēdzieni tiek sajaukti. Autora vārda kopēšana teksta laukā sākumā šķiet vienkārša, taču vēlāk apgrūtina autora profila atjaunošanu. Savukārt katras nelielas izvēles pārvēršana atsevišķā entītijā rada nevajadzīgu administrēšanu. Projektēšanas mērķis nav maksimāli sarežģīta shēma, bet pietiekami precīza struktūra paredzamajiem lietojumiem.

Sāciet ar lēmumiem, nevis administrācijas formu

Pirms lauku saraksta jānosaka, kādi lēmumi un darbības būs atkarīgas no datiem. Praktiska sākuma secība ir šāda:

1. Apkopojiet galvenos satura izmantošanas scenārijus: publicēšana mājaslapā, filtrēšana, meklēšana, atkārtota izmantošana, eksports un nodošana citām sistēmām.
2. Nosauciet patstāvīgos biznesa objektus, nevis esošās lapu veidnes.
3. Katram objektam piešķiriet stabilu identifikatoru un skaidru atbildīgo lomu.
4. Aprakstiet laukus, statusus un attiecības neatkarīgi no konkrētā CMS ekrāna.
5. Pārbaudiet modeli ar tipiskiem, nepilnīgiem un robežgadījumu ierakstiem.

Satura tipu nevajadzētu veidot tikai tāpēc, ka divas lapas vizuāli atšķiras. Vienam strukturētam pakalpojuma objektam var būt vairāki attēlojumi. Pretējā virzienā viena līdzīga dizaina veidne var rādīt dažādas entītijas ar atšķirīgu dzīves ciklu. Dizains nosaka prezentāciju, bet modelis — datu nozīmi.

Noderīgs sākuma katalogs var izskatīties šādi:

Tabula vēl nav datubāzes shēma. Tā palīdz vienoties par objektiem pirms tehniskās realizācijas.

Kā projektēt laukus ar nepārprotamu nozīmi

Katram laukam dokumentējiet nosaukumu, semantiku un izmantošanas noteikumus. Minimālais lauka apraksts ietver:

•          nemainīgu tehnisko nosaukumu;
•          redaktoram saprotamu etiķeti un paskaidrojumu;
•          datu tipu un, ja vajadzīgs, formātu;
•          pieļaujamās vērtības un validācijas robežas;
•          obligātumu konkrētā dzīves cikla posmā;
•          noklusējuma vērtību, ja tai ir biznesa pamatojums;
•          vienas vai vairāku vērtību atļauju;
•          valodas un lokalizācijas noteikumus;
•          piekļuves, sensitivitātes un datu izcelsmes nosacījumus.

Tehnisko nosaukumu, piemēram, publication_date, vēlams uzskatīt par stabilu līguma daļu. Redzamā etiķete var mainīties, taču tehniskā nosaukuma maiņa var skart API, veidnes, eksportus un analītiku. Neskaidri nosaukumi, piemēram, extra_text vai field_2, pārnes šodienas steigu uz nākamajiem uzturētājiem.

Izvēlieties šaurāko datu tipu, kas atbilst nozīmei. Datuma vērtībai izvēlieties datuma vai datuma un laika lauku. Brīvs teksts tam nav piemērots. Fiksēta biznesa izvēle jāglabā kontrolētā vērtību kopā, jo uz vienādu pareizrakstību nevar paļauties. Naudas summai vajadzīga arī valūta; attēlam var būt vajadzīgs alternatīvais teksts, izmantošanas tiesību informācija un fokusa punkts.

“Obligāts” nenozīmē, ka laukam jābūt aizpildītam jau tukša melnraksta izveides brīdī. Daļa noteikumu var darboties statusa pārejā: melnrakstu drīkst saglabāt nepilnīgu, bet publicēt — tikai pēc nepieciešamo datu pārbaudes. Tas ļauj saglabāt darba elastību, nesamazinot publicētā satura kvalitātes prasības.

Struktūru, tipus un validācijas nosacījumus iespējams aprakstīt mašīnlasāmā shēmā. JSON Schema specifikācija piedāvā kopīgu pamatu JSON dokumentu struktūras un ierobežojumu aprakstīšanai, taču pati shēma neaizstāj vienošanos par lauku biznesa nozīmi.

Statusiem jāapraksta darba plūsma

Statuss ir jēgpilns tikai tad, ja ir zināms, kas drīkst tajā ieiet, kas drīkst no tā iziet un kādas pārbaudes notiek pārejas laikā. Vienkāršā redakcijas plūsmā var būt šādi stāvokļi:

Katras pārejas aprakstā norādiet atļauto lomu, obligātos laukus, automatizētās darbības un auditā saglabājamo informāciju. Piemēram, pārejot uz “Publicēts”, sistēma var pārbaudīt virsrakstu, URL identifikatoru un publicēšanas kanālu, kā arī reģistrēt izpildītāju un laiku.

Sarežģītākā vidē redakcijas statuss jāatdala no publicēšanas stāvokļa. Saturs var būt apstiprināts, bet vēl nepublicēts, vai publicēts vienā kanālā un ieplānots citā. Vienā laukā apvienojot apstiprinājumu, laiku un kanālu, statusu skaits strauji pieaug un to nozīme kļūst neskaidra. Mazai viena kanāla vietnei apvienota plūsma var būt pietiekama, ja tās robežas ir dokumentētas.

Datu attiecībām vajag noteikumus abās pusēs

Relācija jāizmanto, ja saistītajam objektam ir sava identitāte, dzīves cikls vai atkārtots lietojums. Raksta autors parasti ir atsevišķa entītija, jo vienu autoru izmanto vairāki raksti un viņa profilu jāspēj mainīt vienuviet. Turpretī vienreizējs ievada teksts parasti ir raksta lauks.

Katrai attiecībai jāatbild uz pieciem jautājumiem:

1. Kāda ir kardinalitāte — viens pret vienu, viens pret daudziem vai daudzi pret daudziem?
2. Kura puse ir attiecības īpašnieks un kur to rediģē?
3. Vai secībai ir nozīme?
4. Kas notiek, ja saistīto objektu arhivē vai dzēš?
5. Vai saite attiecas uz aktuālo objektu vai konkrētu tā versiju?

Dzēšanas uzvedību nedrīkst atstāt nejaušībai. Iespējamā politika ir aizliegt dzēšanu, kamēr pastāv atsauces, atstāt tukšu saiti, arhivēt objektu vai kontrolēti dzēst atkarīgos ierakstus. Automātiska kaskādes dzēšana ir piemērota tikai tad, ja atkarīgajam ierakstam bez vecākobjekta nav patstāvīgas nozīmes. Relāciju integritāti datubāzes līmenī var nostiprināt ar ārējām atslēgām; PostgreSQL ierobežojumu dokumentācija apraksta primārās un ārējās atslēgas, unikālos un pārbaudes ierobežojumus.

Ne katrai izvēlei vajag relāciju. Ja vērtību kopa ir maza, stabila un bez papildu atribūtiem, var pietikt ar kontrolētu izvēles lauku. Ja vērtībai vēlāk vajadzēs tulkojumu, aprakstu, hierarhiju, atbildīgo vai savu arhivēšanas procesu, atsevišķa entītija būs elastīgāka. Izvēles pamatā jābūt paredzamajai pārvaldībai. Ieviešanas ērtums vien nav pietiekams pamatojums.

Modelējiet izmaiņas jau pirms pirmās migrācijas

Pārvaldāms modelis nav tāds, kuru nekad nemaina. Tam ir noteikta izmaiņu procedūra. Pirms jauna lauka, statusa vai relācijas ieviešanas jānoskaidro:

•          kurš biznesa scenārijs izmaiņu prasa;
•          kuri esošie ieraksti un integrācijas tiks skarti;
•          kā tiks aizpildīti vēsturiskie dati;
•          vai vecā un jaunā struktūra īslaicīgi pastāvēs paralēli;
•          kā pārbaudīs migrāciju un kā rīkosies kļūdas gadījumā;
•          kad veco lauku drīkst pasludināt par novecojušu un vēlāk noņemt.

Droša lauka aizstāšana parasti notiek pakāpeniski: izveido jauno lauku, definē pārveides noteikumu, migrē datus, pārbauda rezultātu, pārslēdz lasītājus un rakstītājus, bet veco lauku noņem tikai pēc atkarību pārbaudes. Tūlītēja pārdēvēšana administrācijas panelī var būt tikai vizuāla izmaiņa vai arī shēmas izmaiņa ar plašām sekām — tas atkarīgs no CMS realizācijas.

Jānošķir satura versija no modeļa versijas. Satura versija atbild uz jautājumu, kas mainījās konkrētā rakstā, savukārt modeļa versija norāda, kā mainījās pati datu struktūra. Migrācijas žurnālā ir lietderīgi saglabāt shēmas versiju, izpildes laiku, skarto ierakstu apjomu, kļūdas un izmantoto pārveides noteikumu. Tas neizslēdz risku, bet padara izmaiņu pārbaudāmu.

Praktisks piemērs: pakalpojuma satura tips

Pieņemsim, ka CMS jāglabā uzņēmuma pakalpojumi. Minimālais modelis varētu ietvert stabilu ID, iekšējo nosaukumu, publisko virsrakstu, īso kopsavilkumu, strukturētus satura blokus, atbildīgo kontaktpersonu, kategorijas, galveno attēlu, SEO laukus un publicēšanas iestatījumus.

Te svarīgi nepieļaut trīs saīsinājumus. Ja kontaktpersonai jau ir patstāvīgs profils, tās datus nevajag kopēt vairākos teksta laukos. Kategoriju ierakstīšana ar komatiem neder, ja pēc tām paredzēta filtrēšana. Arī visas lapas glabāšana vienā neierobežotā HTML laukā nav piemērota, ja atsevišķas daļas būs jāizmanto sarakstos, meklēšanā, strukturētajos datos vai citā kanālā.

Vienlaikus nav jāsadala katrs teikums atsevišķā laukā. Strukturēti satura bloki ir saprātīgs kompromiss, ja redaktoram vajadzīga kompozīcijas brīvība, bet sistēmai — zināmi bloku tipi un validējami atribūti. Modeļa detalizācijai jāatbilst tam, ko sistēma patiešām filtrēs, atkārtoti izmantos vai nodos tālāk.

Pirms ieviešanas aizpildiet vismaz vairākus atšķirīgus piemērus: tipisku pakalpojumu, pakalpojumu bez cenas, pagaidu piedāvājumu, vairāku kategoriju pakalpojumu un arhivējamu ierakstu. Tas nav statistisks kvalitātes apliecinājums, bet praktisks veids, kā atklāt neatbildētus modeļa jautājumus.

Modeļa pārbaudes kontrolsaraksts

Pirms satura modeļa apstiprināšanas pārbaudiet:

•          vai katrai entītijai ir skaidra identitāte un īpašnieks;
•          vai katram laukam ir viena definēta nozīme;
•          vai tehniskie nosaukumi nav piesaistīti īslaicīgam dizainam;
•          vai obligātums tiek pārbaudīts pareizajā darba posmā;
•          vai statusu pārejas, lomas un atteikuma ceļi ir dokumentēti;
•          vai attiecībām ir kardinalitātes un dzēšanas noteikumi;
•          vai lokalizējamie un kopīgie dati ir nošķirti;
•          vai API patērētājiem ir zināmas iespējamās shēmas izmaiņas;
•          vai vēsturisko datu migrācijai ir pārbaudes un atcelšanas plāns;
•          vai redaktors var saprast formu bez mutiska skaidrojuma no izstrādātāja.

Pēc ieviešanas modeļa veselību var vērtēt pēc praktiskiem signāliem: validācijas kļūdu veidiem, neizmantotiem laukiem, bāreņu saitēm, statusos iestrēgušiem ierakstiem, biežiem manuāliem labojumiem un integrāciju kļūdām pēc shēmas izmaiņām. Šie rādītāji jāinterpretē kontekstā. Piemēram, daudz kļūdu var norādīt gan uz nekvalitatīviem datiem, gan uz nesaprotamu formu vai pārmērīgi stingru noteikumu.

Ierobežojumi un riski

Detalizēts satura modelis nav pašmērķis. Nelielai vietnei ar dažām reti maināmām lapām var pietikt ar vienkāršāku struktūru. Pārāk agrīna abstrakcija rada daudz entītiju, relāciju un redaktora darbību, kurām nav reāla lietojuma. Savukārt daudzkanālu publicēšana, apjomīgi katalogi un vairākas integrācijas parasti prasa stingrākus noteikumus un stabilākus tehniskos identifikatorus.

Ar datu modeli vien nepietiek drošībai un pārvaldībai. Atsevišķi jāprojektē piekļuves tiesības, darbību žurnāli, rezerves kopijas, atjaunošana, personas datu apstrāde un integrāciju kļūdu vadība. Arī datubāzes ierobežojums nevar pārbaudīt katru biznesa nozīmi; daļa noteikumu jāīsteno lietotnē un darba plūsmā.

Juridiski, finanšu vai citādi regulētiem datiem lauku glabāšanas termiņus, piekļuvi un dzēšanu nevar noteikt tikai tehniskā komanda. Šādos gadījumos modelis jāsaskaņo ar attiecīgās jomas atbildīgajiem. Ja prasības vēl nav zināmas, labāk dokumentēt pieņēmumus un paredzēt pārskatīšanas punktu, nevis pasniegt pagaidu izvēli kā nemainīgu patiesību.

Secinājums

Labs CMS satura modelis ir vienošanās par datu nozīmi un pārmaiņu kārtību. Lauku skaits pats par sevi tā kvalitāti nenosaka. Svarīga ir spēja saprotami atbildēt, ko katrs lauks nozīmē, kas drīkst mainīt statusu, kā objekti ir saistīti un kas notiks nākamajā shēmas izmaiņā. Ja šīs atbildes ir dokumentētas un pārbaudītas ar reāliem scenārijiem, CMS ir daudz vieglāk uzturēt arī tad, kad mainās komanda, dizains vai integrācijas.