Lagdelt arkitektur for KMP

Etter hvert som KMP-appen vokser, kan den delte koden bli uoversiktlig. En tydelig lagdelt arkitektur holder hver del på sin plass, slik at begge appene fortsatt er enkle å endre.

De fleste KMP-apper ender opp med tre lag: data, domene og presentasjon. Hvert lag har én oppgave, og avhengighetene går i én forutsigbar retning.

Data-laget kommuniserer med omverdenen: Ktor for HTTP og SQLDelight for lagring. Det henter rå byte og sender rensede data oppover, samtidig som detaljene skjules.

Domene-laget inneholder forretningsreglene og modellene. Det vet ingenting om HTTP eller SQL, så det forblir rent, portabelt og svært enkelt å teste.

Presentasjons-laget klargjør tilstanden for skjermen. Delte ViewModels hører hjemme her og gjør domenedata om til StateFlow-en som hvert brukergrensesnitt samler inn.

Gullregelen er at ytre lag avhenger av indre lag, aldri omvendt. Presentasjonen kjenner domenet; domene kjenner ingen av nab lagene.

Lag kobles sammen gjennom interfaces, ikke konkrete klasser. Domenet erklærer hva det trenger, mens data-laget leverer implementasjonen, slik at De fritt kan bytte ut deler.

Hvert lag kan ha sine egne datatyper: en nettverks-DTO i data-laget og en ren modell i domenet. Mapping mellom dem hindrer særtrekk ved API-et i å lekke inn i reglene.

Separasjon lønner seg når kravene endres. Bytt ut et REST-API med GraphQL, så er det bare data-laget som endres; domenet og presentasjonen merker ingenting.

Data, domene og presentasjon kan alle ligge i commonMain. Både Android og iOS gjenbruker hele stakken og leverer bare den endelige plattformspesifikke skjermen.

De trenger ikke ti lag den første dagen. Begynn med disse tre, hold avhengighetspilene ryddige, og la strukturen vokse først når det faktisk er nyttig. 🙂

De delte den felles koden inn i data, domene og presentasjon, lot avhengighetene peke innover og koblet lagene sammen gjennom grensesnitt. Tydelige grenser og enkle endringer. 🎉