Opleverdocument Spotitube

Gemaakt door: Bastiaan van Kleef

 1. Inleiding
Dit document is gemaakt als een beschrijving voor de keuze die zijn gemaakt in het maken van de
Spotitube casus. Hiervoor zijn er een package diagram en een deployment diagram gemaakt.
Daarnaast zijn overige keuzes ook beschreven.
 2. Package diagram
Hieronder is het package diagram te zien deze verwacht dat een gebruiker altijd contact zal maken via
de controller. Hierna zullen de controllers naar de desbetreffende service gaan en daarna zal deze
service verder gaan naar de data laag. De data laag zal hierbij communiceren naar de database.
 3. Deployment diagram
Hieronder is het deployment diagram zichtbaar. In dit deployment diagram is de keuze gemaakt om de
database via docker te laten runnen. Dit staat als een apart component omdat dit ook op een ander
artifact kan runnen. De OS die boven staat aangegeven wordt bedoelt als de client die een call doet
naar spotitube. In de toekomst zal dit de front-end zijn.

4. Ontwerp-/Craftmanship -keuzes
In dit hoofdstuk zal ik verschillende ontwerpkeuzen beschrijven en aangeven dat ik heb gewerkt
volgens de SOLID principes.

4.1 Lagen
Ten eerste is de applicatie gescheiden in drie lagen, namelijk: de controller laag, de service laag en de
data laag. Deze verschillende lagen zijn op zo’n manier gebouwd dat deze zo min mogelijk van elkaar
afhankelijk zijn. Dit heeft als gevolg dat de verschillende delen van de applicatie makkelijker
onafhankelijk van elkaar te testen zijn. Ook creëert dit de mogelijkheid om de applicatie in de
toekomst makkelijker uit te breiden. Dit volgt dan ook de SOLID principes met de Singel
Responsibility en de Open en Close.

Er wordt hierbij ook nog gebruik gemaakt van de Inject functie zodat deze lagen nogwel met elkaar
kunnen communiceren.

4.2 Datasource
De verantwoordelijkheid van de datasource is dat hij moet communiceren met de database. In deze
laag wordt constant data heen en weer gestuurd tussen de applicatie en de database door middel
van prepared statements. Hierbij worden deze statements direct naar de database gestuurd. Een
risico hierbij kan zijn dat wanneer er aanpassingen gedaan worden aan de database dat de code
hierdoor ook direct niet meer zal werken.

4.3 Data Transfer Objects

Als er vanuit de datasource laag een call wordt gedaan wordt er een resultset meegegeven. Een
resultset is alleenstaand binnen Java niet heel vriendelijk om mee te werken, dit is waarom er
gebruik wordt gemaakt van DTO’s (Data Transfer Objects). Data Transfer Objects zijn Java objecten
die precies dezelfde structuur hebben als de binnenkomende resultset. Door hun getters en setters
zijn deze makkelijk in gebruik te nemen door functies. Ook kan hij makkelijk als argument worden
doorgegeven naar een mapper.
Om het nog makkelijker te maken om hiermee te werken zijn datamappers gerealiseerd.
Datamappers zijn klassen die door de functies uit de datasource laag worden aangeroepen om
inkomende resultsets vanuit de database naar het gewilde DTO te converteren.

4.4 Information hiding

Tijdens het schrijven van het domein is er nagedacht over het hiden van de information. Dit is zodat
informatie van het domein niet zomaar aangepast kan worden. Hierbij zijn wel allemaal getters en
setters gemaakt zodat als deze informatie aangepast moet worden. Dat het zo ook gedaan kan
worden.