Dette perspektiv beskriver teknikken bag det valgte arkitektur og strukturen af denne, dvs. f.eks. lagdeling, valg af væsentlige arkitekturkomponenter osv.

Teknisk design for Serviceplatformen - Det fælles datagrundlag (DFDG)

DFDG som er den fælles serviceplatform og fælles datagrundlag på beskæftigelsesområdet ønskes opbygget via Microsoft-teknologi i en Microservice-arkitektur, hvor hver microservice modsvarer de byggeblokke der er beskrevet under Forretningsservice-perspektivet. Systemet har følgende skematiske opbygning:

Here are the new patterns:

• Ambassador can be used to offload common client connectivity tasks such as monitoring, logging, routing, and security (such as TLS) in a language agnostic way.
• Anti-corruption layer implements a façade between new and legacy applications, to ensure that the design of a new application is not limited by dependencies on legacy systems.
• Backends for Frontends creates separate backend services for different types of clients, such as desktop and mobile. That way, a single backend service doesn’t need to handle the conflicting requirements of various client types. This pattern can help keep each microservice simple, by separating client-specific concerns.
• Bulkhead isolates critical resources, such as connection pool, memory, and CPU, for each workload or service. By using bulkheads, a single workload (or service) can’t consume all of the resources, starving others. This pattern increases the resiliency of the system by preventing cascading failures caused by one service.
• Gateway Aggregation aggregates requests to multiple individual microservices into a single request, reducing chattiness between consumers and services.
• Gateway Offloading enables each microservice to offload shared service functionality, such as the use of SSL certificates, to an API gateway.
• Gateway Routing routes requests to multiple microservices using a single endpoint, so that consumers don't need to manage many separate endpoints.
• Sidecar deploys helper components of an application as a separate container or process to provide isolation and encapsulation.
• Strangler supports incremental migration by gradually replacing specific pieces of functionality with new services.

Hub and spoke - i forhold til DFDG data

Applikationer der trækker på data fra DFDG - En applikation er et it-system, der løser en eller flere specifikke forretningsbehov. Det vil typisk være et system med en brugergrænseflade vendt mod en sagsbehandler eller en borger, eller et system, der foretager en række beregninger/handlinger på de registrerede data.

Den typiske STAR applikation vil trække på data om borger eller virksomhed fra DFDG, evt. suppleret med data fra eksterne kilder, typisk suppleret med data fra egen database, hvis applikationen behandler data, der ikke er omfattet af DFDG.

Tanken er, at STAR’s applikationer bygges efter ”Hub and spoke” løsningsmønstret, sådan at alle datatyper, hvor DFDG indeholder masterdata, udveksles direkte via DFDG. Dvs. applikationerne går direkte til kilden. De enkelte applikationer kan i visse tilfælde af hensyn til performance gemme en lokal kopi af data, en cache. Det anbefales dog, at anvendelse af cachede data minimeres af hensyn til kompleksiteten.

Figur: Hub-and-spoke arkitektur med DFDG i midten

Applikationerne opdeles så vidt muligt i afgrænsede forretningsmoduler med et entydigt forretningsansvar.

For at se konkret eksempel på anvendelsen se f.eks.:

• Dataflow mellem DFDG og aftagere

Overordnet applikationsarkitektur