Domänen i fokus, Portar, Adaptrar och Hexagonal Arkitektur Presentation

28 February 2025 // Björn Beskow

Presentation från Cadec 2025 Göteborg

Presentation från Cadec 2025 Stockholm

Den till synes oundvikliga komplexiteten som plågar de flesta mjukvaruprojekt kommer ofta från beroenden mellan delar av lösningen, beroenden som över tid blir ohanterliga och leder till “legacy” (även känt som “big ball of mud”). Arkitekturarbetets kanske viktigaste uppgift är som bekant att bromsa denna ökande “mjukvaru-entropi” genom att begränsa och kontrollera beroenden med hjälp av abstraktioner, lagerindelning och arkitekturella principer som t.ex SOLID. De allra mest stabila och värdefulla delarna i en mjukvarulösning är de som också är viktigast att skydda mot osunda beroenden: domänen eller kärnverksamhetens regler och beteende.

Ironiskt nog kan en traditionell, “endimensionell” lager-indelning motverka detta syfte, genom att premiera det “understa” lagret. Det är skälet till att man i DDD-lägret allt oftare pratar om en annan, “flerdimensionell” lagerindelnig med domänen i centrum, omgiven av “portar” och “adaptrar” i en lökskalsmodell med det något kryptiska namnet Hexagonal Arkitektur.

I den här presentationen tittar vi närmare på denna arkitekturella stil, och finner ett användbart verktyg i DDD-arkitektens verktygslåda med (i vanlig ordning) ett antal avigsidor.

Frågor och svar

Bör man separera lager i olika projekt i samma lösning eller räcker det med folder struktur och överenskommelser inom team?

Varför inte separera domänlogiken helt som en egen tjänst?

Modularisering kan ju göras på olika sätt, från deploy/runtime-separation (olika processer), buildtime-separation (olika projekt och bygg-artefakter) till de modulariserings-mekanismer som ens programmerings-språk/plattform erbjuder (paket, namespace etc.). Det viktiga är att lager-indelningen/modulariseringen och de principer som styr den upprättas och efterlevs. ArchUnit och liknande verktyg ger bra stöd för att säkerställa att reglerna följs.

Hur ska man göra en avvägning för att undvika att man måste in i mängder med lager när man tex lägger till ett attribut? Jämför tex med hur Ruby on Rails tacklar detta.

Betyder detta att man lätt behöver duplicera dataklasser i varje lager för mappningen?

Abstraktion och strikt lager-indelning har absolut ett pris: “Samma” information kan behöva representeras i flera (och ibland samtliga) lager, och kod behöver skrivas och underhållas för att transformera/mappa mellan dem. Poängen med separationen är ju dock att det som initialt är “samma” över tid kan utvecklas åt olika håll och i olika takt. När så sker, ger abstraktionen/separationen sitt värde, innan dess innebär den bara merarbete. Därmed är denna arkitekturstil inte kostnadseffektiv för alla tillämpningar (som t.ex. enkla CRUD/register-vårds-applikationer eller stödtjänster utanför kärnverksamheten där man kan tänka sig att slänga och bygga/köpa nytt efter hand). För de tillämpningar som utgör kärnverksamheten (som måste kunna förvaltas och vidareutvecklas över lång tid) är abstraktionen/separationen däremot kritisk, och den extra ansträngning som transformation mellan separata representationer väl värd sitt pris. Moderna mappningsverktyg som t.ex. MapStruct eller JMapper kan med fördel användas för att minimera ansträngningen och komplexiteten.

Blir det fler lager med Hexagonal Arkitektur?

Det blir inte fler lager, men ansvarsgränserna mellan lagren blir tydligare i och med att explicita portar och adaptrar separerar dem.