mandag 17. 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:
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:
Hvis tre lag er bra må jo fem, eller kanskje åtte, være enda bedre:
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:
Databasen utgjør jo et fint API, ikke sant? Ikke det? Ok, hva med denne da:
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å...
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:
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.
Wild messaging er state of the art SOA. En generisk meldingsbuss sørger for at tjenester kan snappe opp hendelser de er interesserte i.
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.
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.
Og det var det – 11 illustrasjoner av hvordan vi utviklere setter sammen baller av kompleksitet.