Véleményem és tapasztalatom szerint a megjelenítési rétegtől a Db-ig haladva a változások száma csökken, míg azok kockázata nő.
Milyen rétegek? Természetesen a klasszikus 3-rétegű alkalmazások. Megjelenítő, üzleti logika és a perzisztencia. Ez az elhatárolás alapvetően logikai, de a gyakorlati megvalósítás is gyakran tükrözi.
Én alapvetően hiszek az adatmodell változatlanságában. Ez a változatlanság nem azt jelenti, hogy nem kell megfelelő kontroll nélkül belenyúlni az adatmodellbe és ezzel együtt a fizikai implementációba, azaz a konkrét adatbázis szerkezetbe. Azt vallom, hogy, az üzleti folyamatok megismerése után egy ellenőrizhetően jó adatmodellt lehet felállítani. Erre különféle adatbázis tervezési sablonok/minták állnak rendelkezésre. Elég komoly irodalma van ezen a gyűjteményeknek, amiben megismerhető, hogy milyen lehetséges modellje van egy HR-rendszernek, készletnyilvántartásnak vagy akár egy accounting systemnek. Példának itt van a legelső, amit a kereső nekem kidobott: Data Model Patterns.
A fenti nézőpontból látszik, hogy nem a változás ellen vagyok. Szerintem ezek gyakorisága meglehetősen behatárolható. De lássuk szintenként is. Felülről lefelé. (Bár, ha jobban belegondolok a hagymahéj hasonlat jobb lenne. Nem találom a linket, de talán Alistair Cockburn-tól származik.
Vegyünk egy már működő alkalmazást. Ez egyszerűsítés, de nem hibás és nem is szükséges más megszorítás. Manapság már ritka a teljesen új program. Mindnek van előzménye, vagy maga a mindennapi funkció használt régóta (levele az elektronikus szövegszerkesztők előtt is írtak, csak akkor nem a copy-paste az olló és papír volt némi titkárnői segítséggel). A programtól csak hatékonyságnövelést várnak. (EVO alapvetés)
Az funkciók adottak, de nem tetszik a képernyőn lévő szövegek formája, alakja, tartalma. A szövegszerkesztőnek teljesen mindegy, hogy "Edit" vagy "Szerkesztés" szöveg van, amíg az alatta lévő funkció megegyezik. Vagy a szöveg betűtípusa, esetleg a képernyő elrendezése. Ne itt legyen a gomb, hanem ott. Igen-igen! Bagatell dolgok, de akkor is léteznek. Mint tudjuk a programok használatának élvezetét 90%-ban ezek határozzák meg. Miért alakította át a MS az Office 2007 menüjét? Miben más a levelezés a Gmailben, mint a Freemail-ben? Válasz, nincs különbség. Az első csoportban szöveget szerkesztünk, a másodikban levelet írunk. Csak apróságokban térnek el. MS a felhasználók mindennapi viselkedését vizslatta meg. A Gmail talán legnagyobb újítása, hogy az egy témához tartozó beszélgetéseket természetes módon, automatikusan egybe rendeli. Pedig se tárolásban, se funkcióban nem jelent más, "csak" a kliens speciális módon szűri és fésüli össze a leveleket. Hasonló: mindenféle klikkellgetés helyett a drag-and-drop. Legalapvetőbb testre szabás minden üzleti alkalmazásrendszerben: a különféle riportok. Minimum a céglogó mindbe bele kell tenni. Üzleti oldalról kicsi az ilyen funkciók bevezetésének kockázata, de számuk óriási.
Középrétegben lévő üzleti logika mindennemű változás, bizonyítás nélkül látható, hogy nagyobb kockázatot jelent. Kihatása összetett. Alapvető, hogy egy benne végbemenő változás triviálisan kihat a megjelenítendő adatokra. Változik a workflow, változik a teljes üzletmenet, esetleg a teljes használat is. De itt dominánsan a funkciókról és azok egymásutániságáról van szó. Extra üzleti funkció lehet a folyamat beillesztett új nyomtatás, extra visszacsatolás az eddig jobbára egyenes munkafolyamatba. Az ilyen módosítások is csaknem mindennaposak a bevezetési fázisban, hiszen ez szól arról, hogy adaptáljuk a kliens céghez. (hangsúlyozom, hogy a bevezetés egy már meglévő szoftverrendszer testre szabása esetén értem. Vadonatúj fejlesztések esetében kicsit más, de nem alapvetően.)
Az adatbázis módosulások csaknem a teljes alkalmazásra kihathatnak. Nem feltétlenül, de tapasztalatom szerint túl szoros a kapcsolat a db-szerkezet és a megjelenítés között. Mondjuk ebben is van igazság, hiszen adatokat adunk be és módosítunk. Az teljesen biztos, hogy egy adatbázis módosítás kockázatosabb, hiszen kihat minkét korábbi rétegre is. Ha az adatbázisban gáz van, akkor nem csak a mi alkalmazásuknak lőttek, hanem minden másiknak is, ami azokból az adatokból él. Az üzleti életben kevés olyan adatbázis van, ami csak önmagéban kerek egész. Könyvtári adatbázist összekapcsolják másik könyvtári adatbázissal. Kockázatkezelő modul a hitelszámla-vezetővel, áruszállításnál a beszállítási adatokat kell átvinni/transzformálni a raktármodulba és értesíteni kell a könyvelést is. Az adatok koherenciája alapvető. Ha ebben hiba van, akkor átgyűrűzik a rendszer minden részére. Egy címke átírása nehezen fogja a könyvelés munkáját megnehezíteni.
Érveimben lehet hibát találni és kérlek is, hogy keress! Minél több visszajelzést kapok, annál jobban letisztulnak a gondolataim és látásmódom. Ha nincs igazam, akkor meghajlok a jó érvek előtt, de az is lehet, hogy erősebb érveket is fel tudok hozni.
Kritikára fel Fiatalok!
