Det gode forretningsdomæne (tidligere: silo)
- Kasper Birkelund Larsen (Unlicensed)
- Kasper Birkelund
- Kim Jørgensen
Det store overblik
Alle forretningsdomæner (siloer) er beskrevet i denne oversigt over målsystemlandskabetWebservice-struktur (TO-BE på moderniserende DFDG webservice)
Før oprettelse af et forretningsdomæne
Inden oprettelsen af et forretningsdomæne skal de grundlæggende principper for domænet være på plads: Navn for forretningsdomænet, forretningsdomænets ansvarsområde og forretningsdomænets afhængighed af andre forretningsdomæner - events der skal abonneres på og events der skal udstilles. Se evt. https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2257158358
Oprettelse af et forretningsdomæne
Selve oprettesen sker ved at følge checklisten for oprettelse af nye forretningsdomænerhttps://starwiki.atlassian.net/wiki/spaces/CITY/pages/2398421661
Brug og videreudvikling af et forretningsdomæne
Når først forretningsdomænet er oprettet, skal de enkelte services og metoder implementeres og databasen skal opsættes. De nye forretningsdomæner er født med en demo service som skal fjernes ifm oprettelsen af den første service.
Der er en række principper der skal overholdes for forretningsdomænerne således vi får et ensartet og vedligeholdelseslet landskab af forretningsdomæner:
Udviklingsprincipper og designmønstre for de nye forretningsdomæner
Principper og navngivning i forhold REST services
Principper for event drevet arkitektur, herunder event og brugen af Event Brokeren i forhold til servicekald
Vi laver ikke service kald mellem de enkelte domæner, ud over til og fra DFDG klassik (som teknisk set ikke er et domæne). Mellem de enkelte domæner basere vi kommunikationen på events som beskrevet her: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2522874147/Star.Foundation+-+EventBroker
Principper for kodelister og brugen af samt udstilling af kodelister fra andre forretningsdomæner
Principper for fejlhåndtering, herunder fejlkoder.
Fejlhåndteringen for metoder er beskrevet i detaljer her https://starwiki.atlassian.net/wiki/spaces/FYS/pages/13926417/Fejlh+ndtering
Principper for databaseadgang, herunder også hvordan vi laver revisionshistorik
Vi har beskrevet den gode database her hvor designprincipperne for hvordan vi ønsker at arbejde med databaser er beskrevet: https://starwiki.atlassian.net/wiki/spaces/FYS/pages/13926405/Den+gode+database
Historik for tabeller bliver håndteret af databaseserveren selv vi temporale tabeller: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/1654587579/Star.Foundation+-+Historik
Revisionshistorikken er implementeret dels via historik på fact tabellerne så man kan se hvordan data har udviklet sig over tid, dels via metadata feltet i tabellerne hvor man kan se hvem der er ansvarlig for handlingen/ændringen. Metadata og brugen deraf er beskrevet på denne side: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/1654718588/Star.Foundation+-+Metadata
Initial load af data i nye forretningsdomæner
Dataload i det nye forretningsdomæne laves af BI. De har ansvar for datamigration og det initielle load på testmiljøer og i produktion ifm release. Til brug for dette laves i en user story en mapning af eksisterende tabeller/felter til nye tabeller/felter i samarbejde med BI.
Principper for GDPR
I de enkelte forretningsdomæner er GDPR sletninger implementeret som almindelige batchjobs der kører direkte under Stonebranch, og ikke som subjobs til conducter jobs som i DFDG klassik. Det er jobbes eget ansvar at terminere efter en vis kørselstid så frem det ikke blot skal slette alt der kan slettes. I forbindelse med sletning af data, bliver vi nødt til at frakoble den automatiske historik, beskrevet herhttps://starwiki.atlassian.net/wiki/spaces/FYS/pages/3864100877/Den+gode+GDPR-sletning+Temporal+Tables
Det er de enkelte domæners ansvar at slette både data ejet af domænet og data replikeret fra andre forretningsdomæner.
Principper for duplering af data i forhold til self-contained applikation
De enkelte forretningsdomæner skal kunne fungere uden at andre forretningsdomæner er tilgængelige. I dag har vi dog en forretningsrest i DFDG (DFDG klassik) som er nødvendig at nå via servicekald da ikke alt er eventunderstøttet endnu. Dette betyder at vi kan have kaskadeafhængighede hvor et forretningsdomæne kalder DFDG Klassik, der igen kalder et andet forretningsdomæne.
Målet er at al forretning er delt ud i forretningsdomæner, der alle kommunikere med hinanden via asynkrone events. Hvert forretningsdomæne holder de data det har brug for lokalt, og holder data ejet af andre forretningsdomæner up-to-date ved at abonnere på events. Dette betyder at centrale oplysninger som fx. en borgers kontaktgruppe er gemt i stort set alle forretningsdomæner.