Versions Compared

Old Version 6

changes.mady.by.user Per Persson

Saved on

compared with

New Version 7

changes.mady.by.user Per Persson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Alternativ a: Datalagret bygger specifika vyer i databasen för det data som skall hämtas från en mikrotjänst i samtliga fall.

  • Alternativ b: Mikrotjänsterna går direkt mot tabeller och kolumner i Datalagrets databas om inte en vy krävs av prestandaskäl.

Gliffy
imageAttachmentIdatt950042682
macroId16a2522e-d5d4-41ac-a311-ed1b287cedfe
baseUrlhttps://sundsvall.atlassian.net/wiki
namedatalagerAPIaltAB
diagramAttachmentIdatt950370314
containerId950042626
timestamp1646303858168

Alternativ 1

Alternativ 2a

Alternativ 2b

Pros and cons

(plus) Korrekt funktionsallokering

(plus) Inga beroenden mellan olika team

(minus) Frågan om utökat driftansvar för BODIL-maskinen måste redan ut

(minus) Resursbrist i hos Datalagret (är väl bara Joel som är aktuell för utvecklingen just nu)

(plus) Resursfrågan mindre akut

(minus) Funktionsallokering/
ansvarsfördelning alls inte optimal

(minus) Dubbel utveckling för varje ny datamängd (skapa vy i Datalagret samt logik i mikrotjänst)

(plus) Resursfrågan minst akut

(minus) Funktionsallokering/
ansvarsfördelning alls inte optimal

Utvärdering

Data samt dess API hanteras inom samma objektförvaltning, vilket talar för detta alternativ

Detta alternativ går bort som standard-alternativ - att alltid behöva utveckla på två ställen när en ny datamängd skall exponeras är det sämsta alternativet

Kompetens- och resursmässigt är detta den bästa lösningen - dock är ansvarsdelningen inte optimal och vi riskerar “blame-games”

...