Microservice Architecture
This section gives an overview of the RDS architecture.
Clean Architecture
The service system in RDS is built on the concept of SOLID principles and Robert C. Martin's Clean Architecture. Especially the concept of layers and dependencies:
source: Robert C. Martin
RDS Layers
Layers are indexed from the outermost to the innermost. RDS consists of the following layers:
- Layer 0 contains services that provide the functionality of the entire RDS backend to the integration plugins.
- Layer 1 contains services that connect external and internal services to RDS. The containers in this layer are called Ports.
- Layer 2 contains services that implement features. These containers are called Use Cases.
- Layer 3 contains services that store information or are so essential for the entire system that they cannot be omitted. These containers are called Central.
Diagram
This diagram shows the data flow within the RDS ecosystem. Each service is linked, you can quickly look up the corresponding documentation by clicking on the respective node. Incoming connections are established by the EFSS plugin (e.g. Owncloud).
EFSS Integration
The integration of the RDS application into an EFSS system (integration platform) is realized as a native plugin through the platform's own plugin system. The plugin wraps the RDS standalone application into an iFrame and is not part of the described layering structure.
Due to the diverse landscape of EFSS software, RDS has to provide the highest possible integration diversity. For this the responsibility is handed over to the target platform: There must be a plugin system that allows for the integration of third-party applications. Owncloud is the first target platform. Further integrations must adhere to the Oauth2 concept. RDS only implements and makes available API endpoints.
RDS uses the first token it receives for a user of an integration platform as the main token, all subsequently added tokens assigned to the same user and integration platform are interpreted as connected services and offered to the user for selection. This also results in the use of unique user names or IDs for each integration platform. Although the same user name or ID may occur several times in RDS, it must be possible to attribute it uniquely to the integration platform.
It is also easy to implement new integrations with other repository services, as the new service must offer Oauth2 and the user must be able to authorise himself to RDS with this service. All services integrated with RDS can then be given to the user to choose and authorise, so that RDS can authorise itself to them on behalf of the user. RDS offers a lot of different API endpoints, so that the integration can focus on displaying and sending requests and not on implementing complex algorithms.