Undersøge arkitekturmæssige design, der følger best practice og kan udstille ekstern port samt håndtere kald til eksterne API’er.

Afsøgte materiale omkring arkitekturdrevet design fra tidligere semestre, søgte på nettet efter alternativer.

Layered architecture blev afsøgt, da det kunne bruges, hvis man erstattede repository-laget med fx en type GoogleVisionClient.
Ønsker dog på sigt at kunne implementere flere versioner af billedgenkendelsestjenester, således at resultaterne kan sammenlignes. Bevæget mig derfor væk fra denne idé.

Orienterede mig i Hexagonal design, også kaldet Ports and Adapters. Dette er en softwarearkitektur, hvor man ser for sig en sekskantet boks. I midten af denne boks er al domænelogikken. Rundt omkring denne logik finder man “porte” (interfaces), og på ydersiden af disse porte sidder “adapters”, som forbinder kernen til omverdenen.

Man har to sider af den sekskantede boks: På den indkommende side, hvor man modtager data, findes Driving side – altså det, der initierer handlingen. På den anden side har man Driven side, dvs. den, der bliver kaldt. Driving side sender input ind i kernen, mens driven side er den del, der sættes i gang.

Driving side = input -> systemet
Dette er her en adapter starter en Use Case. Driven side = systemet -> output Dette er her en adapter udfører noget på vegne af domænet, fx API-kald til AI-analyse.

Umiddelbart synes Hexagonal architecture at være et godt match, der kan gøre koden robust og skalerbar. Der virker desuden til at være gode muligheder for test, da domænelogikken er adskilt og uafhængig. Nye adapters kan implementeres uden indflydelse på forretningslogikken da de skal forholde sig til domænets kontrakter, såkaldt Dependency Inversion. Der vil desuden være en klar separation of concerns.

Ulemper med arkitekturen er, at der kan opstå meget boilerplate-kode, der skal skrives, samt interfaces og implementeringer af disse. Ved større applikationer kan der opstå latenstid, men det vurderes ikke som tilfældet ved vores projekt.