správny návrh viacerých verzií jedného systému a API rubrika: Návrh
3
pooler
v rámci práce, robím na jednom obrovskom systéme (ktorý sa už robí nejaký ten rok a ešte nejaké tie roky bude robiť)
bol zvolený taký postup, že budú vydané 3 verzie systému (aby sa nečakalo X rokov, kým to bude všetko spravené)
verzia Lite, Pro, Enterprise - všetky tieto 3 verzie budú samostatné produkty
Lite verzia je veľmi zjednodušená Pro verzia ... a Pro verzia je zjednodušená Enterprise verzia
návrh Entít je však robený pre Enterprise verziu
v rámci ďalšieho predajného produktu sa bude robiť aj REST API, ktoré má byť spravené pre Enterprise verziu ... a tak sa s ním aj pracuje
Lite a Pro verzia majú údaje získavať cez API ... takže musia mať vlastnú správu viacerých veci, musia robiť X requestov naviac, aby mohli správne vytvoriť konkrétnu entitu
konkrétny príklad:
API pre vytvorenie predstavenia:
POST /performance - name - CostCenter - start_date - end_date - Location - private - FormatVideo|NULL - FormatAudio|NULL - EventVersion|NULL - EventAccessibility|NULL - ExpirationType|NULL - ExpirationValue|NULL - Vat - allow_selling - allow_discounts - allow_reservations - Mark|NULL - Event
v Lite verzií, sa však použije iba:
- name - CostCenter - start_date - end_date - Location - private - Vat - allow_selling - Event
popis predstavenia je v entite Event, ktorá vyzerá takto:
- original_name|NULL - production_year|NULL - EventType - description - genres: [] - roles: [] - origin_countries: [] - premieres: []
v Lite verzií sa pri Event používa iba description a EventType
keďže Lite je niečo samostatné, tak pre vytvorenie predstavenia cez API musí najprv:
- zistiť všetky CostCenter a vybrať, ktoré sa použije (robí to lite systém, nie klient)
- pred vytvorením Performance, musí najprv vytvoriť Event (robí to lite systém, nie klient)
takýchto veci bude musieť Lite robiť automaticky viacero, keďže ma správne používať API najvyššej verzie
moja otázka znie, je takýto postup návrhu správny ?
alebo by Lite verzia mala používať iné API, prispôsobené práve jej ?
8
rmaslo
Celé to rozdělení na Lite, Pro, Enterprise mi přijde dost nepraktické a spíše takové "obchodnické" než "programátorské" a obávám se, že než se aplikace dodělá tak se obchodnické požadavky mohou změnit a pokud je to zadrátovné do aplikace takovýmto způsobem tak to i může přestat vyhovovat.
Postupoval bych klasicky, tak jak je v oboru zvykem. Tj. vytvořit uživatele, skupiny a práva. Práva se většinou dělají na formuláře jednotlivých agend, ale samozřejmě se mohou nastavovat na tabulky a jak je v tomto případě požadavkem i na jednotlivé sloupce tabulek.
Navíc v této části zadání se o právech uživatelů nemluví, pokud se s nimi počítá, tak vlastně není potřeba nic extra programovat, pokud o nich obchodníci zatím nemluví tak je to jen asi ještě nenapadlo :-). A s takovýmto návrhem jsem připraven i na to, že ze tří verzí udělají dvě nebo čtyři a že to nakonec nebude třeba po sloupcích agendy, ale po agendách (což je mnohem běžnější) atd..
Takže souhlas s Kitem, udělal bych to jako jednu aplikaci (se stejným API) a "verze" řídil právy.
Pro zobrazení všech 5 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře