Die Plattform ist als Schichten organisiert, jede mit einer eigenen Verantwortung, verbunden statt isoliert.
Wie die Plattform strukturiert ist
Jede Schicht — Governance, Standards, Architektur und so weiter — ist eine eigene Disziplin, aber jede Schicht ist so gestaltet, dass sie mit den anderen zusammenarbeitet, nicht isoliert davon.
Schichten und ihre Verantwortlichkeiten
Governance definiert Entscheidungsrechte und Betriebsregeln; Architektur hält bedeutsame Design-Entscheidungen fest; Delivery macht Releases vorhersehbar und wiederholbar.
Wie Architekturentscheidungen festgehalten werden
Bedeutsame Design-Entscheidungen werden als Architecture Decision Records dokumentiert, zusammen mit ihrem Kontext und ihren Abwägungen, nicht nur ihrem Ergebnis.
Beispiele
Eine Beispielkonfiguration, eine Übersichtstabelle der Komponenten und ein kurzer Tab-Überblick darüber, wie diese Architektur einem neuen Team üblicherweise vorgestellt wird.
Eine minimale Umgebungskonfiguration für eine lokale ETES-Instanz:
ETES_API_URL=https://api.etes.local
ETES_ENV=development
ETES_LOG_LEVEL=info| Komponente | Typ | Beschreibung |
|---|---|---|
| API Gateway | Dienst | Leitet eingehende Plattformanfragen weiter und authentifiziert sie. |
| Standards Engine | Dienst | Bewertet Inhalte und Konfiguration anhand aktiver Standards. |
| Documentation Store | Daten | Speichert versionierte Artikelinhalte und Metadaten. |
Die Plattform ist in eine kleine Anzahl zusammenarbeitender Dienste statt in einen einzigen Monolithen unterteilt, sodass sich jeder Bereich unabhängig weiterentwickeln kann.
Jeder Dienst liest seine Konfiguration beim Start aus Umgebungsvariablen — es gibt keinen gemeinsamen veränderbaren Konfigurationsspeicher zwischen ihnen.
Dienste stellen eine versionierte HTTP-API bereit; interne Aufrufe zwischen Diensten verwenden dieselben Verträge wie externe Integrationen.