Hosszú évek alatt rájöttünk, hogy a vállalati programok terén már szinte mindent feltaláltak. Megnéztük tehát, hogy hogyan dolgoznak a vezető szoftvercégek, majd ezen alapelvek, ajánlások és framework-ök "összegyúrásával" alakítottuk ki a saját keretrendszerünket. Ez nagy kezdeti befektetést igényelt, ami később többszörösen megtérül, mert kitűnő minőségű, könnyen kezelhető és bővíthető szoftver lesz az eredmény.
Keretrendszerünk "sarokkövei" az alábbiak:
SOLID
100%-ban objektumorientált kód nem létezik, de minden fejlesztőnek törekednie kell ennek elérésére. A SOLID irányelvei a minőségi kódolás alapjait képezik, betartásuk nélkülözhetetlen a korszerű vállalati rendszerek fejlesztéséhez.
Domain-driven Design (DDD)
A Domain-driven Design metodológa szerint a jól működő üzleti alkalmazások alapjai az üzleti objektumok. A fejlesztés legfontosabb része tehát a való élet feladatainak leképezése a megfelelő entitásokra, amelyek tulajdonságokat és cselekvéseket (logikát) tartalmaznak. Ez a folyamat a modellezés, a domain objektumokat így gyakran modelleknek is nevezik. A tervezéshez elengedhetetlen a megrendelővel kialakított szoros együttműködés, hatékony kommunikáció, vagyis a közös nyelv (ubiquitous language) kialakítása.
Sokrétegű architektúra
A sokat emlegetett két- vagy háromrétegű ("kliens-szerver") megoldások ideje lejárt. Szoftvereink felépítésének koncepciója az Onion (hagyma) architektúrán alapszik, amely több, koncentrikusan egymásra épülő rétegből áll. A "hagyma" külső rétegei hozzáférnek a belsőkhöz, belülről kifelé azonban semmiféle függőség nem hozható létre. Ebből következik, hogy a fejlesztés is belülről kifelé halad.
A belső magot a hagyományos rendszerektől eltérően nem az adatbázis, hanem az üzleti objektumok, domain-ek képezik (lásd: DDD). A következő réteg tartalmazza az üzleti logikát, vagyis a domain objektumokhoz kapcsolódó cselekvéseket, szabályokat. Ebben a rétegben egy korszerű, rugalmas megoldást, a CQS-t alkalmazzuk.
Az adatbázishoz való hozzáférés az infrastruktúra réteg feladata, amely a "hagymán" kívül található, így tetszőlegesen kicserélhető, helyettesíthető bármivel. Ez a megoldás az automatizált tesztelés (lásd: TDD) egyik legfőbb kritériuma. A felhasználói felület szintén egy külső réteg, amely a lehető legkevesebb üzleti logikát tartalmazza, így minimális befektetéssel akár több különböző platformon futó több felület is tartozhat ugyanazon alkalmazáshoz. Webes alkalmazás esetén a felhasználói felületet további rétegekre bontjuk az MVC modell irányelvei alapján.
A szoftver rétegei között nincs közvetlen függőség, ehelyett a hozzárendelés a Dependency Injection metodológia alkalmazásával történik. Ez a rétegek futásidejű összekapcsolását jelenti, amelyhez mi az NInject framework-öt használjuk. Ez a módszer az automatizált tesztelés másik fontos alapkövetelménye.
Test Driven Development (TDD)
A 21. századi komplex rendszerek minőségi kihívásainak csak tesztvezérelt fejlesztéssel lehet megfelelni. Az adott funkcionális elem fejlesztésének már a legelején elkészülnek az első unit tesztek, amelyek a többi egységtől külön vizsgálják a programrész működését a lehető legtöbb aspektusból (test case). A külső függőségeket (pl. adatbázis) ebben a szakaszban leegyszerűsített "hamis" objektumokkal (mock) helyettesítjük. Az automatizált tesztelés a felhasználói felülettől függetlenül történik.
A fejlesztés végén készítjük el az integration teszteket. Ezek már a végső környezetükben, a többi réteggel összekötve, valós adatbázisokkal vizsgálják a működést. Lehetőség van a felhasználói felület automatizált tesztelésére is, webes alkalmazás esetén pedig külön teszteket készítünk a kliens oldali szkriptekre is.
Az elkészült tesztek a forráskód részei. A tesztek rendszeresen, akár ütemezve is futtathatók, így még a verzió kiadása előtt felderíthetőek a továbbfejlesztések miatti rejtett hibák.
Adatbázis-független megoldások
Többrétegű architektúránk része, hogy az üzleti objektumok és az adatbázis közötti összeköttetést ORM-mel (Object-relational Mapping, ami a mi esetünkben az NHibernate framework) valósítjuk meg, ami függetleníti az alkalmazást az adatbázistól. Az entitások tulajdonságaihoz tábla- és mezőneveket rendelünk, ezután már nem kell foglalkozni az adatkezelési műveletekkel, ezeket az infrastruktúra rétegben lévő ORM automatikusan elvégzi. Rendszereinkhez elsősorban Microsoft SQL Server vagy Oracle szervert ajánlunk, de ezzel a megoldással bármilyen, ingyenes, vagy akár nem relációs adatbázishoz is csatlakozhatunk.
Eszközfüggetlenség
A számítástechnikai berendezések közti határok mára elmosódtak, az asztali PC-k helyét lassan átveszik a mobil eszközök a legkülönbözőbb operációs rendszerekkel, kijelzőkkel és beviteli módszerekkel. Egyetlen közös jellemzőjük, hogy mindegyiken elérhető a 3-4 széleskörűen elterjedt webböngésző legalább egyike. A sávszélesség növekedésének és a mobil kapcsolatok fejlődésének köszönhetően napjainkban az eszközfüggetlen szoftverek leghatékonyabb és legolcsóbb módja a webes technológia.
Szoftvereink felhasználói felülete 100%-ig reszponzív, így bármilyen méretű kijelzőn használható, az elterjedt böngészők bármelyikén megjeleníthető. A HTML5/CSS3 szabványoknak és a javascript eszközöknek köszönhetően használatuk ugyanolyan kényelmes, mint a már megszokott Windows alapú ügyviteli rendszereknek.
Webes kliens oldali framework-ök
Az elmúlt években a nyílt forráskódú javascript eszközök terén is hatalmas fejlődés tanúi lehettünk, melynek eredménye a webböngészőkben megjelenő kiemelkedő funkcionalitás. A szoftvereink felületét alkotó komponensek használják a jól bevált, széles körűen elterjedt JS alapú megoldásokat (JQuery UI / Mobile, Bootstrap, Angular JS, EasyUI, Underscore stb.). Ezeken kívül még számos javascript framework-öt használunk kisebb részfeladatok megoldására a diagram-rajzolástól a PDF exportig.