Fenomenet jag tänker på är att det verkar finnas en princip för arkitekturen i många projekt som säger att ”ju fler lager, desto bättre”. Det är åtminstone mycket vanligt i Dotnet- och Javaprojekt. Speciellt i de projekt som kallas enterpriseprojekt.

Varför blir det så här? Drivkrafterna är många, men följande sticker ut som de vanligaste:

• ”Många lager kan vara bra att ha. Man vet aldrig när ett lager visar sig vara nyttigt.”
• ”Personen X/boken Y säger att det ska vara så.”
• ”All kod skall vara likartad och följa samma struktur.”

Jag tycker alla anledningarna ovan är riktigt dåliga. Den första är ett utmärkt exempel på olycksfallskomplexitet. På spekulation ökas komplexiteten i förväg. Det är bäst att låta bli och spekulera och göra saker så enkla som möjligt i stället så att de är ändringsbara när, eller om, det behövs.

Den andra anledningen brister vad gäller ”context is king”. Ingen lösning är alltid den bästa, det beror naturligtvis på situationen.

Men kanske allra värst är anledning tre. Antingen så ska koden inte vara likartad eftersom det är olika problem och olika situationer. Eller om den kan vara likartad så låter det som ett allvarligt brott mot DRY (Don’t Repeat Yourself). Troligen ska den inte handskrivas över huvud taget.

Någon skrev för ett tag sedan att ”Arkitektur är som lasagne. Ju fler lager, desto godare.”

Jag håller absolut inte med. Varken vad gäller arkitektur eller lasagne. Smaken sitter inte i antalet lager. Faktum är att det citatet får mig att bli sugen på spagetti.

Vilka är hakarna av att ha fler lager än vad som är rätt antal?

• När något ska ändras så finns en tendens att ändringen påverkar mer än ett ställe i koden på grund av för många lager.
• Du får massor av helt ointressant kod och mycket kod innebär att det är mer att läsa och det tar längre tid att lokalisera vad man söker.

Sammanfattningsvis så blir det dyrare att underhålla, helt enkelt.

Det verkar vara en vanlig tendens att utvecklare följer en cykel. I skolan och tidiga projekt börjar man med all kod i ett enda lager.

Därefter går man över till en extrem mängd, kanske åtta till tolv lager regelmässigt, för att slutligen vara situationsanpassad och låta den valda lösningen på problemet styra vad som är rätt antal.

Det angreppssätt som jag rekommenderar är att man inte lägger fokus på lager till att börja med i nya projekt, utan fokuserar på att förstå problemet och beskriva lösningen så enkelt som möjligt.

I takt med att behoven av lager sedan visar sig så lägger man till dem, men först efter att kritiskt ha utvärderat värdet i förhållande till kostnaden.

Flest lager vinner alltså inte.