Microservice Architecture

Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Microservices Architecture

Source: ISO/IEC/IEEE 42010:2022

Source reference: https://www.iso.org/standard/74393.html

Additional information: Microservices architecture decomposes an application into smaller, loosely coupled services. Each service is responsible for a specific functionality and can be developed, deployed, and scaled independently. Services communicate with each other through lightweight APIs or messaging protocols. This architecture enables flexibility, scalability, and easier maintenance, but it introduces complexities in managing distributed systems.

Example: Title: Microservices Architecture Decision Record (ADR)

LOST view: Digital Solution Architecture Decisions Catalogue view

Identifier: http://data.europa.eu/dr8/egovera/MicroserviceArchitectureGoal

EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal

ABB name: egovera:MicroserviceArchitectureGoal

EIRA concept: eira:ArchitectureBuildingBlock

Last modification: 2023-08-20

dct:identifier: http://data.europa.eu/dr8/egovera/MicroserviceArchitectureGoal

dct:title: Architecture Decision Record about Microservices Architecture

eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons.

eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how.

eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)]

eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture.