MAOV-systemet følger et design-pattern der kaldes "layers" 1) 5). Det går ud på at systemet er opbygget af lag på forskellige abstraktions-niveauer, som udnytter hinanden, og på den måde gør de enkelte lags opgaver mere afgrænsede og overskuelige.
At MAOV er blevet lagdelt kommer sig i høj grad af at de systemer det er designet til er delt op i lag. Det øverste lag er WAP-telefonen (e.lign) og det nederste lag er Oracle's databaser med bl.a virksomhedsoplysninger. Der er langt imellem de to lag, men heldigvis er der standard-komponenter der kan lægges imellem de to ydre lag, så de mødes i midten i et Java-baseret lag, hvor MAOV kommer til at ligge. I den øvre ende er det Portal-to-Go der skaber bro mellem WAP-telefonen og Java, og i den nedre ende er det JDBC, der skaber bro imellem Oracle-databaserne og Java. I midten ligger så det rent Java-baserede MAOV-system, som sørger for at det er de rigtige data der kommer fra Oracle-databaserne til WAP-telefonen.
På denne grove model, er MAOV-systemet umiddelbart kun et lag, men det er i sig selv også delt op i flere lag, hvilket de andre lag i den grove model iøvrigt også er. Men lad os først se på specifikationen på et "layered" design-pattern.
Et lagdelt system er et ordnet sæt af virtuelle verdener, som hver er bygget udfra det underliggende lag, og leverer basis-funtionalitet for laget ovenover. Et lag kender kun laget lige under sig, dvs. det kender hverken lag længere nede, eller lag over sig.
Der er et alternativ til denne såkaldte "lukkede arkitektur", som kaldes "åben aktitektur". I den åbne er det tilladt for lag at bruge samtlige underliggende lag direkte. Det kan give en optimeret og mere kompakt kode, men gør lagene langt mere afhængige af at de andre lag ikke ændres. Man vil derfor oftest fortrække den lukkede.
Et velkendt eksempel på layers er netværks-protokoller der typisk ligger i lag, hvor de nederste er mest hardware-specifikke, og de øverste er aplikationerne som brugerne ser.
I et større system vil det ikke altid være tilstrækkeligt at dele systemet op i vandrette lag. Man kan derfor kombinere opdelingen vandret med lodret opdeling i subsystemer. På den måde får man en slags blokdiagram over hvilke dele systemet består af, og hvilke der ligger over hvilke
MAOV er primært delt op i to lag. Et lag der genererer XML-dokumenterne til brugerne (GUI-buildere), og et lag der henter de fornødne oplysninger fra databasen (Data-fetchere). Dertil kommer tre hjælpelag der henholdsvis skaber forbindelsen til Portal-to-Go, distribuerer opgaverne og skaber selve forbindelsen til databasen. De to primære lag er desuden delt op i tre subsystemer udfra deres afgrænsede funktion (Customer, Employee og Pricelist) plus et fjerde subsystem (action-point) som var tiltænkt at kunne støtte de tre andre. Customer-subsystemet er det mest komplekse, og er derfor yderligere delt op.
Hoved-delen af systemet er de 6 kasser i midten af modellen. De er delt ind vandret i de to lag, og lodret i de tre subsystemer. Subsystemerne går altså på tværs af lagene, eller sagt med andre ord, de tre subsystemer er ens opdelt i lag. De tre subsystemer fungerer nogenlunde ens, men bruger ikke hinanden. Action-point subsystemet er meget lille og derfor ikke delt i de to lag, som man kunne mene at det burde. Det bruger til gengæld både DBAccess og SendEMail som underliggende lag.
Denne opdeling minder meget om systemets opdelingen i klasser, som illustreret på ICE-modellen. Mange af klasserne, har her fået deres eget sub-system. "Task-distributør"-laget er dog lidt specielt, idet det er delt ud over flere klasser. Specifikt udgøres den af invoke-metoden som er nogenlunde ens i de forskellige objekter den er implementeret i, og derfor har en logisk funktion som sit eget lag. Det ligger dog reelt indbygget i de andre lag, derfor er den illustreret som overlappende.
Den primære idé med at dele systemet op de to lag var at adskille database-tilgangen fra den del af systemet der bygger siderne op som skal vises til brugeren. Den ene halvdel af systemet henter data, og den anden halvdel sender dem videre.
MAOV-systemet har ikke kun et lag-delt design, men det er en del af det samlede design, og det følger specifikationerne. De underliggende lag kender ikke de overliggende lag, men tilbyder den basis-funktionalitet de kræver. Det er en lukket arkitektur, da der ikke er nogen der springer lag over.