Funderingar och fantasier

Jag lyssnade till en föreläsning om domändriven design eller som det kort och gott kallas DDD. Allt med genomslag har en bokstavskombination. Intresset var större än vad arrangörerna räknat med. De hade tvingats boka en större lokal.

En detalj som föreläsaren tog upp var hans förändrade syn på lager inom programutvecklingen. Han hade byggt programvara med många lager men blivit varse nackdelar när ändringskraven kommer. Underhållet blir tyngre då ändringen måste in i alla lager. Tidsödande och kostsamt. Det väckte min uppmärksamhet så här kommer min fundering runt ämnet.

En vanlig separering av programvaruutveckling är i lagren för presentation, affärslogik och databas. Det är vad jag vill kalla ett horisontellt perspektiv. Lagren ligger seriekopplade från användarytan över affärslogik till databaslagret. Samma abstraktionsnivå. En vanlig bokstavskombination i dessa sammanhang är MVC. Där M:et står för modell eller databärare. V för view det vill säga det som presenteras för användaren och slutligen C som står för controller vilket kontrollerar flödet. Perspektiv är här mer kopplat till programmeringsperspektivet men fortfarande horisontellt.

Lager kan också ses utifrån ett vertikalt perspektiv. Eller ska vi tala om abstraktionsnivåer. Om vi resonerar i databastermer så har vi på lägsta nivå teckenhantering. Nästa nivå har tecknen samlats i kolumner. Ytterligare en nivå är formatet som består av ett antal kolumner. Här kan vi också prata om block där flera format samsas. På samma sätt kan presentationslagret delas upp i vertikala lager. Tecken på lägsta nivå och om vi resonerar i html-termer har vi taggarna som ingår i element. Flera element bildar visuella enheter och till slut kommer vi upp till användarytans hela HTML-sidor. Jag vill lyfta fram denna horisontella syn på utvecklingsarbetet. Kan arbetet lyftas till en högre nivå där enheterna är block finns stora vinster att hämta. Både tidsmässigt och stabilitetsmässigt.

Låt mig ta ett exempel. Hantering av XML kan ske på många olika sätt. Nätet är fullt av verktyg. Säljare säger sig ha de nödvändiga redskapen, dock mot en smärre(större) kostnad. Arbetet med XML kräver just deras redskap. Det måste vara okunskap som gör det möjligt att sälja verktyg när det finns bra hantering av XML i många språk. I javan finns bland annat JAXB som ett utmärkt exempel. Med dess hjälp kan man lyfta hanteringen en eller ett par nivåer. Finns definitioner över xml:en i form av schema eller DTD så kan klasser genereras direkt. Vi har flyttat oss högre upp och jobbar på objektnivå eller om man så vill blocknivå. Enkelheten blir uppenbar. Omvandlingen mellan xml och klasser sker med en enda kodrad. Saknas definitioner finns också möjligheten att generera definitioner direkt från xml-filen. Om vi återvänder till resonemanget kring vertikala lager så har vi lyft oss några nivåer. Antalet kodrader som behöver skrivas minimeras. Stabiliteten blir bättre och utvecklingstiden blir betydligt kortare. Utvecklare måste kunna lämna detaljnivå.

I min förra fundering sammanfattade jag min syn på den del av IT-branschen som jag kommit i kontakt med på följande sätt. Data kommer in, lagras och plockas ut för presentation. Då gick jag vidare med den mellersta delen lagring. Denna gång riktar jag blicken mot den första delen. Hur kommer uppgifterna in i systemen. Utgångspunkt för funderingen får bli ett försök att besvara följande fråga. Vem och var görs inmatningsarbetet?

Första svaret på min fråga blir personal inom den egna organisationen. De ansvarar för registreringsarbetet. En tidsödande uppgift speciellt om det är omfattande uppgifter som ska in. Formulären optimeras för att underlätta och snabba upp registreringen. Saker som gruppering av kolumner och tab-ordning blir viktiga.

Något som blivit allt vanligare är att uppgifter tas in från externa källor. Uppgifterna batchas in. Det kan bli allas egendom då de gamla kostsamma EDI-lösningarna efterhand ersätts med betydligt enklare och billigare web-service funktioner. Här finns en stor marknad för integration av kund/leverantörsrelationer. Företag som tagit till sig web-service tekniken har här stora möjligheter. Svaret på vem och var blir i detta fallet någon annan organisation som exporterar sina registrerade uppgifter och som tas in via mer eller mindre automatiska importfunktioner.

Den tredje typen är när registreringsarbetet flyttas ut från organisationen helt och hållet. Sociala medier som Facebook, Twitter och nu senast i raden Google+ är typexempel. Skalet för registreringen tillhandahålls men innehållet kommer in utifrån. Kunderna får själva stå för inmatningen av uppgifter. Till denna kategori hör också web-shoppar. Kunderna registrerar sin beställning i form av artikel och antal direkt i ordersystemet. Den egna organisationen befrias från kostnaden av registreringsarbetet. Även försäljningsarbetet i butik har på sina ställen tagit denna väg. Kunderna sköter själva scanningen av varorna och kassaarbetet själva. Företeelse att flytta ut registreringsarbetet från den egna organisationen är på frammarsch.

Den del av IT-sektorn som varit min kontaktyta mot arbetslivet kan sammanfattas i följande mening. Data kommer in, lagras och plockas ut för presentation. Svårare än så är det inte. Låt oss titta närmare på den mellersta delen lagring. Jag vill lyfta fram några problemställningar och förändringar.

De stora databaserna som DB2, Oracle och SQL-server har dominerat. Gemensamt är stödet för en allmän SQL-standard men också väl tilltagen prissättning och minimering av förändringsbenägenheten. Stödet för stora objekt så kallade Blob:ar har tillförts liksom implementering av XML. Förändringar som kommit sent. Först när marknaden tagit andra vägar.

Från utbildningstiden drar vi oss till minnes tragglandet av normalformerna. Allt för att hitta uppdelningen av tabeller och varje tabells unika nyckelvärde. Senare har användandet av surrogatnycklar tillkommit för att underlätta arbetet med SQL-satser. Problematiken mellan objekthanteringen och databas har varit föremål för en omfattande debatt. Den som gått under namnet ORM, object relational mapping. Hela framework har växt fram. Inom java-världen är Hibernate det mest kända.

Genom de stora drakarnas prissättning kom mySQL gratisversion som en frisk fläkt och blev defaktostandard för webapplikationer. Det är dock en annan tendens jag vill lyfta fram. Drakarnas tröghet har banat väg för något som går under namnet NoSQL. Till en början fanns tolkningen “no SQL” dvs säga nej till SQL-databaserna. Senare förtydligat till “not only SQL”. Inom termen ryms ett brett spektra av olika lagringsformer. De vanligaste kan hänföras till någon av grupperna “key value store”, “column based”, “document database” eller “graph database”.

I gruppen dokumentdatabaser som får betraktas som efterföljare till Lotus Notes finns bland annat MongoDB. En databas som jag försökt tillföra min verktygsportfölj. Flexibiliteten är en av fördelarna jag ser. Det finns ingen låsning till en statisk tabellstruktur. Den är också lätt att ta till sig om man kommer från SQL-lägret. Här finns också lagringen av stora objekt som alternativ till de traditionella blobarna.

En annan grupp som intresserat mig är är graph databaserna. Därför har jag placerat Neo4J på undersökningsbordet. Uppgifterna i databasen är noder eller relationer mellan noderna. Varje nod eller relation kan ha egenskaper. Í deras argumentering för databasen framhålls prestandan. Jämfört med en traditionell databas kan Neo4j för många applikationer erbjuda en prestandaförbättring upp till tusen gånger. Nu har jag inte utsatt detta för granskning utan min infallsvinkel är en annan. Kan applikationerna förenklas med denna typ av lagring? Jag är beredd att svara ja på den frågan. Flexibiliteten är stor. Potential finns. Problematiken är snarare låsningen av tankemönstren till SQL-modellen.