Fisheries VMS Domain · Lesson 8 of ∞ · ← Lesson 7
Ukraine's e-government layer — and a correction
This lesson corrects an assumption baked into this workspace's own mission statement when it was first written. Worth reading for the correction alone.
Earlier material in this workspace assumed e-Boat is deployed on the Платформа реєстрів / Diia Engine platform. That's wrong. The Customer (Держрибагентство) directed e-Boat to be built beside the platform — its own full stack, integrating with platform-hosted modules purely as an external API client — not hosted on the platform as a new registry. This was confirmed during the tender's own analysis; the MISSION.md and glossary in this workspace have been corrected accordingly. The rest of this lesson explains what that decision actually gives up, and what it keeps.
Платформа реєстрів (English: "Platform for Deployment and Maintenance of State Electronic Registries," internationally referenced as Diia Engine) is a shared government infrastructure for building Ukrainian state registries, operated by ДП «Національний центр реєстрів» under Мінцифри. A registry built on it gets, out of the box:
A registry on the platform still has to supply its own domain logic: business processes, data schema, UI forms, domain validation rules — the platform is DevOps-and-middleware, not a domain expert.
Source: Платформа реєстрів architecture overview (Ukrainian; summarised here in English).
The Customer's directive was explicit: e-Boat is developed beyond the platform's environment, with API-level connectivity to the e-fish modules that do live on it. Practically, this means e-Boat brings its own Keycloak (federating with the platform's for token exchange, not replacing it), its own workflow logic (EBoat.RuleEngine instead of Camunda), its own object storage (MinIO instead of Ceph), its own portal (a standalone Angular SPA rather than the platform's Officer Portal shell) — the entire list from the first section, self-hosted rather than inherited.
None of the source material available answers why definitively — that's a genuine open question, not something to guess at. What's confirmed is the decision itself, and one real consequence: e-Boat cannot assume it gets any of the platform's conveniences for free. Every "the platform normally handles this" instinct needs to be checked against "does e-Boat actually integrate with the platform for this, or does e-Boat own it outright" — and as of this writing, the answer is almost always the latter.
One piece is genuinely undecided rather than settled either way. Trembita (Трембіта) is the platform's interoperability bus — the standard, audited, non-repudiation-guaranteeing plumbing state systems use to exchange data (the same role X-Road-family systems play elsewhere in e-government). For the e-Boat↔eFish integration, the ToR does not mandate Trembita — direct bilateral REST/SOAP is explicitly sufficient. Trembita is on the table as good practice for specific endpoints where an eFish module owner might require state-bus mediation, but that's a per-endpoint decision, owed once the full eFish API catalogue is obtained. Don't present this as resolved in either direction — it isn't yet.
Something unclear, or want to go deeper on any term here? Ask the agent that built this lesson — it's your teacher for this workspace, not just a lesson generator.