Architecture constraints
Technical constraints
| Constraint |
Rationale |
| gRPC for all internal service interfaces |
Provides type-safe, language-agnostic contracts with efficient binary transport. Proto definitions are published in the run-dsrpc repository. |
| Kubernetes as the deployment target |
Enables reproducible, observable deployments managed via FluxCD GitOps. |
Organizational constraints
| Constraint |
Rationale |
| Dataspace communication based on established standards |
The platform currently implements the IDSA Dataspace Protocol as a well-defined, interoperable standard. The requirement is standards-based interoperability; the architecture does not preclude adopting other dataspace protocols as the ecosystem evolves. |
| Gaia-X Trust Framework compliance |
Participant identity must be expressed as Gaia-X-compliant self-descriptions backed by verifiable, DID-based credentials. |
Conventional constraints
These are guidelines, not absolute rules. The goal is quality and shared understanding.
| Convention |
Description |
| Signed commits |
All commits must be GPG-signed. |
| Linting |
Every project enforces a linter in CI. |
| Integration testing |
All services include integration tests. |
| Compliance testing suite |
A dedicated suite verifies conformance with Gaia-X and DSP requirements. |
| E2E testing / BDD |
End-to-end behaviour is specified and verified using BDD-style tests. |
| Code formatter |
Every project enforces a code formatter. |
| Understandable commits |
Commit messages describe what changed and why. |
| No shadow branches |
All work happens on visible, tracked branches. |