Systemarkitektur handlar om att fatta de fundamentala designbesluten för ett mjukvarusystem — hur systemet delas upp i komponenter, hur komponenterna kommunicerar, och vilka principer som styr utvecklingen.
Medan designmönster löser lokala problem (hur en specifik klassstruktur ska se ut), handlar arkitektur om hela systemets struktur.
Varför är arkitektur viktigt?
En dålig arkitektur kan göra ett system omöjligt att underhålla, skala eller vidareutveckla. En bra arkitektur gör tvärtom:
| Bra arkitektur | Dålig arkitektur |
|---|---|
| Lätt att lägga till ny funktionalitet | Varje ny feature kräver omfattande ändringar |
| Komponenter går att testa isolerat | Tester är spröda och långsamma |
| Enkelt att byta ut delar (databas, ramverk) | Systemet är hårt kopplat till specifika verktyg |
| Team kan arbeta parallellt | Alla ändringar påverkar allt |
Arkitektur vs Designmönster
| Arkitektur | Designmönster |
|---|---|
| Global — hela systemet | Lokal — en specifik del |
| Definierar struktur och kommunikation | Definierar klassrelationer och samspel |
| Exempel: MVC, mikrotjänster | Exempel: Singleton, Observer |
| Påverkar utvecklingshastighet, skalbarhet | Påverkar kodkvalitet och underhållbarhet |
Olika nivåer av arkitektur
1. Applikationsarkitektur
Hur en enskild applikation struktureras internt:
- Lagerarkitektur — Presentation → Affärslogik → Dataåtkomst
- MVC — Model-View-Controller
- Hexagonal Architecture — Ports & Adapters
2. Systemarkitektur
Hur flera tjänster eller applikationer samverkar:
- Mikrotjänster — Självständiga, små tjänster som kommunicerar via nätverk
- Händelsestyrd arkitektur — Asynkron kommunikation via events
- Monolit — Allt i en enda enhet
3. Infrastrukturarkitektur
Hur systemet distribueras och körs:
- Moln vs on-premise
- Load balancing, caching, CDN
- Databaser, meddelandeköer
Viktiga arkitekturprinciper
| Princip | Beskrivning |
|---|---|
| Separation of Concerns | Olika ansvarsområden i olika lager/moduler |
| Loose Coupling | Komponenter ska ha minimala beroenden |
| High Cohesion | En komponent ska ha ett tydligt, avgränsat ansvar |
| Don’t Repeat Yourself (DRY) | Undvik duplicering av logik |
| You Aren’t Gonna Need It (YAGNI) | Bygg inte för framtida behov du inte har |
| Principle of Least Astonishment | Systemet ska bete sig som användaren förväntar sig |
Våra arkitekturartiklar
På denna sida hittar du djupgående artiklar om de vanligaste och mest användbara arkitekturstilarna:
- MVC — Model-View-Controller för webbapplikationer
- Clean Architecture — Robert C. Martins lagerbaserade arkitektur
- Mikrotjänster — Självständiga, distribuerade tjänster
- Händelsestyrd arkitektur — Asynkron kommunikation
- Repository Pattern — Abstraktionslager för datalagring
Av Victor Hernandez från Bytebase.se