11 arkitektur-illustrasjoner


søndag 16. september 2012 Softwareutvikling Arkitektur

Jeg har lekt meg litt med noen forsøk på å visuelt illustrere noen typiske software-arkitekturer. Er det noen av disse du kjenner deg igjen i? Jeg begynner med den aller mest gjenkjennelige arkitekturen av dem alle:

bbom

De fleste vet at Big Ball of Mud ikke er særlig bra. For å fikse problemet lærer man at man bør splitte arkitekturen sin opp i lag. Tre lag skal være bra har jeg hørt. Men det kan være lett å missforstå hva det egentlig betyr. Her har dere den vanligste oppdelingen for webprosjekter:

3tier

Hvis tre lag er bra må jo fem, eller kanskje åtte, være enda bedre:

layeres

Den typiske, lagdelte arkitekturen – en stabel med mudballs som balanserer på toppen av en database. Nice! Men hva skjer når vi har behov for flere systemer som må kommunisere sammen? Jo, da trenger vi et integrasjonspunkt:

databaseAPI

Databasen utgjør jo et fint API, ikke sant? Ikke det? Ok, hva med denne da:

inverted_pyramid

Her har vi flyttet integrasjonspunktet ut, og gjenbruker lagene der vi kan. Dette minner faktisk om ganske mange av systemene jeg har vært med å jobbe på. Ser du at det nesten ser ut som en kaktus? Ofte føles det sånn ut også...

soa1

Nå har vi blitt moderne; med Service Oriented Architecture har vi byttet ut den enorme databasen med mindre tjenester som har mindre ansvarsområder og tar vare på sine egne data. Det ser ganske løsrevet og fint ut, men komponentene henger fortsatt for tett på hverandre. For å løse dette introduserer vi en ny, swær mudball:

biztalk

Tjenestene er nå løsrevet fra hverandre, men vi har fått et dyrt monsternav i midten med høy kompleksitet. Utviklere må sitte time etter time for å konfigurere informasjonsstrømmer.

soa2

Wild messaging er state of the art SOA. En generisk meldingsbuss sørger for at tjenester kan snappe opp hendelser de er interesserte i.

pipeline

En meldings-pipeline er én ting man kan få ut av SOA 2.0, og er en typisk arkitektur man kan benytte seg av for å begrense størrelsen på hver enkelt mudball. Tjenestene vet ideelt sett ikke om hverandre, men i praksis flyter meldingene i en fast strøm mellom dem.

p2p

I et P2P-nettverk har man droppet det sentrale navet, og tjenestene må selv sørge for at alle meldinger distribueres der de skal. Det finnes et hav av varianter her...

Til slutt tar jeg med CQRS-arkitekturen, nok en måte å redusere størrelsen på mudballs ved at man skiller behoved på å lese data fra behovet for å gjøre endringer. Denne modellen kan benyttes i hver av tjenestene i de øvrige arkitekturene.

cqrs

Og det var det – 11 illustrasjoner av hvordan vi utviklere setter sammen baller av kompleksitet.


comments powered by Disqus