Registarski vođeni dizajn
PMFA koristi registre za definisanje šema, nametanje konzistentnosti i automatizaciju generisanja UI-a — eliminirajući ručno kodiranje za rutinske operacije.
Problem sa tradicionalnim softverom
U većini sistema, dodavanje novog entiteta (npr. "kategorija proizvoda") zahteva:
- Pisanje šeme baze podataka (SQL migracije)
- Pisanje logike za validaciju na backendu
- Pisanje API endpointa (create, read, update, delete)
- Pisanje frontend formi i tabela
- Pisanje testova za sve gore navedeno
Ovo je sporo, sklono greškama i stvara nekonzistentnosti između slojeva.
PMFA pristup: Registri
U PMFA, definišete entitet jednom u registru. Sistem automatski generiše sve ostalo.
Primer: Definisanje "Materijal" entiteta
{
"entity": "material",
"label": "Materijal",
"description": "Sirovine ili komponente korišćene u proizvodnji",
"fields": [
{
"name": "name",
"type": "text",
"label": "Naziv Materijala",
"required": true,
"max_length": 100
},
{
"name": "supplier",
"type": "ref:supplier",
"label": "Dobavljač",
"required": true
},
{
"name": "batch_number",
"type": "text",
"label": "Šarža/Lot Broj",
"required": false
},
{
"name": "quantity",
"type": "decimal",
"label": "Količina na Stanju",
"required": true,
"min": 0
},
{
"name": "unit",
"type": "enum",
"label": "Jedinica Mere",
"options": ["kg", "litar", "komad", "metar"],
"required": true
}
],
"authority_required": "warehouse.create_material"
}
Šta se automatski dešava
Iz ove pojedinačne definicije, PMFA generiše:
- Šemu baze podataka: Skladištenje činjenica sa ispravnim tipovima
- Logiku validacije: Obavezna polja, min/max, enum provere
- API endpointe: Create, read, query, mutate, revoke
- UI forme: Polja za unos sa labelama i validacijom
- UI tabele: Pregledi lista sa sortiranjem i filtriranjem
- Provere autoriteta: Samo korisnici sa "warehouse.create_material" mogu kreirati
Nula ručnog kodiranja.
Registar kao izvor istine
Registar nije dokumentacija. On jeste sistem.
Ako promenite registar (npr. dodate polje, promenite labelu), ceo sistem se prilagođava:
- Forme se automatski ažuriraju
- API šema se ažurira
- Pravila validacije se menjaju
- Izvoz dokaza uključuje novo polje
Ovo eliminiše nesklad između "šta dokumentacija kaže" i "šta kod radi".
Verzionisanje registra
Sami registri se čuvaju kao nepromenjive činjenice. Kada se šema promeni:
- Kreira se nova verzija registra
- Stare činjenice ostaju validne pod svojom originalnom šemom
- Nove činjenice koriste novu šemu
- Izvoz dokaza uključuje informacije o verziji šeme
Ovo osigurava da stari podaci ostanu tumačivi čak i kada se šeme razvijaju.
Zašto je ovo važno
Brzina
Dodavanje novog entiteta traje minute, ne dane. Nema potrebe za koordinacijom promena na backendu, frontendu i bazi podataka.
Konzistentnost
Svi slojevi (baza podataka, API, UI) su garantovano sinhronizovani jer su generisani iz istog izvora.
Revizibilnost
Promene šeme se prate kao činjenice. Možete videti kada je polje dodato, od koga i zašto.
Ispravnost
Logika validacije se izvodi iz šeme, nije ručno napisana. Smanjuje bagove i granične slučajeve.
Primer iz prakse: WorkshopOS
WorkshopOS definiše ~20 entiteta u svom registru:
- Radni nalozi, klijenti, materijali, dobavljači
- Fakture, uplate, knjižna odobrenja
- Korisnici, uloge, dozvole
Ceo UI (forme, tabele, filteri) je generisan iz ovih registara. Kada se doda polje (npr. "adresa isporuke" na radnim nalozima), forma se automatski ažurira na svim ekranima.
Ograničenja
Registarski vođeni dizajn najbolje funkcioniše za:
- CRUD operacije (create, read, update, delete)
- Standardne validacije (required, min/max, enums)
- Jednostavne relacije (one-to-many, many-to-one)
Složena poslovna logika (npr. višestepeni tokovi odobrenja, prilagođeni proračuni) i dalje zahteva kod. Ali 80% rutinskih operacija može biti registarski vođeno.