Hur modern arkitektur gör jobbet enklare, del 1: CQRS och Användningsfall

Arkitektur ger smidigare och säkrare ändringar, vilket underlättar ett agilt iterativt arbetssätt. Drivkraften är samma som bakom Agile och Lean: att maximera flexibilitet och minimera upprepat/onödigt arbete. Omvänt, svag arkitektur ger svag modularitet, vilket leder till "promiseware" och ”överraskningar” under utvecklingsprojekten (ovanpå extratimmar i kravställandet). 

Ett exempel är Command-Query Responsibility Segregation (CQRS) som en beprövad princip i arkitektur, och användningsfall (Use Cases) som en beprövad teknik i kravfångst för applikationer.

  

CQRS delar upp domänmodellen i två olika, en skräddarsydd för uppdateringar och en för frågor. Att försöka få bägge två att samsas i en gemensam modell kostade oftast utvecklingstimmar, sämre prestanda och skalbarhet, mm. En påkostad flerskiktsarkitektur (n-tier) brukar lämpa sig för uppdateringar, och en enkel tvåskikts (2-tier) för frågor/sökningar.

Användningsfall beskriver hur systemet (som projektet kommer att bygga) ska interagera med olika aktörer i sin omgivning, inte minst hur dialogen med slutanvändare ska gå till i viktiga scenarion, steg för steg. UML:s Användningsfallsdiagram är en grafisk innehållsförteckning över textdokument (som i sin tur brukar struktureras i punktlistor).

Det handlar om interaktivitet, inte om en teknisk lösning. Användningsfall är beprövade inom IT-krav, men har även använts inom säkerhet i USA för att beskriva t ex olika hotbilder (hack, dataspionage, osv). På sistone har de också börjat uppmärksammas av FoU-avdelningar och av innovationsforskare kring bl a Harvard.

Påkostade användningsfall skräddarsydda per händelse (som lägg order, expediera order, betala order...) lämpar sig för värdeskapande affärshändelser (som i regel triggar uppdateringar inne i systemet), och ett förenklat gemensamt ”mall-användningsfall” lämpar sig för triviala händelser där dialogen är i stora drag samma överallt (som Fråga X, Sök Y, Hitta Z, eller Visa sorterad lista över XYZ som uppfyller villkoret...)

I UML Xtra Light – How to Specify Your SW Requirements beskrev jag parametriserade användningsfall lite innan standarden var klar. Cockburn hade då redan publicerat de vanligaste parametrarna för sina “Find” Use Cases: Sorting details, Searchable qualities, Display details (där europeiska företag bör lägga till en underavdelning ”Country details” såsom språk, valutatecken, datumformat, decimalavskiljare). UML 2 standarden fick syntaxbitarna att falla på plats. Parametrisering gäller numera för Operationer, Paket - och inte minst för Classifier som är ett brett samlingsbegrepp för bl a Klasser, Komponenter, Aktörer, och även Användningsfall.

De som använt parametriserade klasser i någon form (template i UML, C++ mm, generic i Java, C#, Ada mm), eller använt OLAP-uttryck med parametrar i stället för fasta attributnamn och konstanter (baserat på Microsofts MDX resp XMLA:s mdXML), inser lätt att under CQRS ger triviala händelser tillfälle till en liknande effektivisering redan i användningsfall...

Den som har sina rötter i mer verksamhet än i IT kan hellre relatera detta till flexibilitetstrenden i affärsprocesserna (late binding i vid bemärkelse, configuration agility, Quote2Order, osv.) där processen inte spikar något i förväg så länge ingen lag eller naturlag kräver det. Parametrisering är konsekvensen, från snabbt ställbara verktygsmaskiner och generisk CAD i fordonsindustrin till klasser och användningsfall i IT.

Mer om parametrisering i användningsfall följer.

/Milan Kratochvil

konsult, Kiseldalen.com

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Samarbetar med Informator sedan våren 1996 inom modellering, UML, analys och design.

Håller f.n. kurserna i modellering med UML, där Användningsfall ingår (T2715, T2716).

(CQRS ingår i kursen Software Architecture, T20112)

Övriga kurser på Informator inom CQRS:

Modern Business Applications with DDD on CQRS