Decoupling der Geschäftslogik: Entwicklung eines unabhängigen API-Gateways #2

New issue

Open

opened 2026-08-30 09:29:52 +00:00 by bjoern · 0 comments

bjoern commented

2026-08-30 09:29:52 +00:00

Collaborator

User Story

Als Entwickler einer externen Anwendung
möchte ich die Geschäftslogik der Plattform über eine stabil definierte, versionierte API (Business Logic Service) anbinden können,
damit ich neue Funktionalitäten schnell in meiner Applikation entwickeln kann, ohne von der ursprünglichen Frontend-Implementierung oder deren Technologie abhängig zu sein.

Einsatzumgebung

Die beschriebenen "externen Anwendungen" können hierbei z. B.

das Alumni-Netzwerk einer Universität,
der Intranetbereich eines Unternehmens oder
die Plattform für Mitglieder einer Industrie- und Handelskammer (IHK), einer Handewerkskammer (HWK) oder anderer Körperschaften des öffentlichen Rechts (K.d.ö.R.)

sein.

Hierdurch ergeben sich zahlreiche Änderungen an den notwendigen Aufgaben, bzw. an den Datenquellen für BizzFed.

Externe Mitgliederverwaltung
Einbindung von Benachrichtigungen (notifications) in bestehende Systeme
Versand von Nachrichten wird eventuell bereits durch ein Fremdsystem angeboten (Einbindung notwendig, falls Direktnachrichten über das ActivityPub-Protokoll erwünscht sind)
Synchronisation von Stellenausschreibungen mit bestehenden Systemen
Strikte Trennung von Daten, die föderiert werden sollen und internen Daten (falls Föderation erwünscht ist)

Notwendige Schritte

API-Definition und -Vertrag: Identifizieren Sie alle notwendigen Geschäftsfunktionen (z.B. CreateJobPosting, FetchUserActivity, SendMessage). Definieren Sie präzise API-Endpunkte, Datenstrukturen (Schema) und Geschäftsregeln.
Service-Extraktion: Isolieren Sie die gesamte Business-Logik (Validierungen, Orchestrierung, Datenbankinteraktion) in einen neuen, unabhängigen Dienst (z.B. Core-Services).
API-Gateway-Implementierung: Errichten Sie eine API-Gateway-Schicht, die als einziger Eintrittspunkt für externe Anwendungen dient und die Anfragen an den neuen Core-Services weiterleitet.
Datenzugriff: Überprüfen Sie, ob der neue Service ausreichend Zugriff auf die Daten benötigt. Erwägen Sie die Bereitstellung von Data-Repositories, die den Zugriff von Frontend/Anwendungen trennen.
Migration und Refactoring: Verändern Sie das ursprüngliche Backend (Hono) schrittweise so, dass es nicht mehr die gesamte Logik enthält, sondern lediglich die Koordination zwischen Frontend und dem neuen Core-Services übernimmt.
Versionierung und Testen: Setzen Sie ein klares API-Versioning (z.B. /api/v1/jobs) ein. Führen Sie umfassende End-to-End-Tests durch, um Regressionen zu verhindern.

Begründung

Skalierung und Resilienz

Die Implementierung eines dedizierten Service-Layers für die Geschäftslogik ist ein fundamentaler Schritt hin zu einer Domain-Driven Architecture (DDA). Aktuell liegt die Geschäftslogik möglicherweise zu stark im View-Layer des bestehenden Backends verstrickt. Indem wir diese Logik isolieren (z.B. in einem neuen Core-Services Microservice), erreichen wir maximale Skalierbarkeit und technologische Flexibilität.

Dieser Ansatz ermöglicht es, einzelne kritische Geschäftsbereiche — wie das Job-Posting-Management oder die Verifizierung von Profilen — unabhängig voneinander zu entwickeln, zu skalieren und zu optimieren. Für bestehende Anwendungen bedeutet dies, dass wir die Komplexität des Originals beibehalten, aber externe Integratoren lediglich einen stabilen, dokumentierten Vertrag (die API) konsumieren müssen. Dies reduziert das technische Risiko bei jeder Erweiterung und macht die Plattform zu einem viel attraktiveren Baustein für Partner und das interne Team. Es ist der notwendige Schritt, um von einem Monolith zu einer Composable Business Platform zu avancieren.

Agilität und Unabhängigkeit

Wir trennen die Geschäftslogik von der Oberfläche. Dies ist entscheidend, weil die Funktionalität (das Was) von der Darstellung (dem Wie) getrennt werden muss. Durch die API stellen wir sicher, dass die Kernfunktionen der Plattform (Job-Postings, Netzwerkanbindung) immer verfügbar sind, egal, welche Technologie ein Partner oder ein neues internes Team verwendet. Das erhöht die Agilität exponentiell und macht unser Produkt zu einer echten, frei integrierbaren Infrastruktur.

# User Story **Als** Entwickler einer externen Anwendung **möchte ich** die Geschäftslogik der Plattform über eine stabil definierte, versionierte API (Business Logic Service) anbinden können, **damit** ich neue Funktionalitäten schnell in meiner Applikation entwickeln kann, ohne von der ursprünglichen Frontend-Implementierung oder deren Technologie abhängig zu sein. ## Einsatzumgebung Die beschriebenen "externen Anwendungen" können hierbei z. B. * das Alumni-Netzwerk einer Universität, * der Intranetbereich eines Unternehmens oder * die Plattform für Mitglieder einer Industrie- und Handelskammer (IHK), einer Handewerkskammer (HWK) oder anderer Körperschaften des öffentlichen Rechts (K.d.ö.R.) sein. Hierdurch ergeben sich zahlreiche Änderungen an den notwendigen Aufgaben, bzw. an den Datenquellen für BizzFed. * Externe Mitgliederverwaltung * Einbindung von Benachrichtigungen (notifications) in bestehende Systeme * Versand von Nachrichten wird eventuell bereits durch ein Fremdsystem angeboten (Einbindung notwendig, falls Direktnachrichten über das ActivityPub-Protokoll erwünscht sind) * Synchronisation von Stellenausschreibungen mit bestehenden Systemen * Strikte Trennung von Daten, die föderiert werden sollen und internen Daten (falls Föderation erwünscht ist) ## Notwendige Schritte 1. **API-Definition und -Vertrag**: Identifizieren Sie alle notwendigen Geschäftsfunktionen (z.B. CreateJobPosting, FetchUserActivity, SendMessage). Definieren Sie präzise API-Endpunkte, Datenstrukturen (Schema) und Geschäftsregeln. 2. **Service-Extraktion**: Isolieren Sie die gesamte Business-Logik (Validierungen, Orchestrierung, Datenbankinteraktion) in einen neuen, unabhängigen Dienst (z.B. Core-Services). 3. **API-Gateway-Implementierung**: Errichten Sie eine API-Gateway-Schicht, die als einziger Eintrittspunkt für externe Anwendungen dient und die Anfragen an den neuen Core-Services weiterleitet. 4. **Datenzugriff**: Überprüfen Sie, ob der neue Service ausreichend Zugriff auf die Daten benötigt. Erwägen Sie die Bereitstellung von Data-Repositories, die den Zugriff von Frontend/Anwendungen trennen. 5. **Migration und Refactoring**: Verändern Sie das ursprüngliche Backend (Hono) schrittweise so, dass es nicht mehr die gesamte Logik enthält, sondern lediglich die Koordination zwischen Frontend und dem neuen Core-Services übernimmt. 6. **Versionierung und Testen**: Setzen Sie ein klares API-Versioning (z.B. /api/v1/jobs) ein. Führen Sie umfassende End-to-End-Tests durch, um Regressionen zu verhindern. ## Begründung ### Skalierung und Resilienz Die Implementierung eines dedizierten Service-Layers für die Geschäftslogik ist ein fundamentaler Schritt hin zu einer Domain-Driven Architecture (DDA). Aktuell liegt die Geschäftslogik möglicherweise zu stark im View-Layer des bestehenden Backends verstrickt. Indem wir diese Logik isolieren (z.B. in einem neuen *Core-Services* Microservice), erreichen wir maximale Skalierbarkeit und technologische Flexibilität. Dieser Ansatz ermöglicht es, einzelne kritische Geschäftsbereiche — wie das Job-Posting-Management oder die Verifizierung von Profilen — unabhängig voneinander zu entwickeln, zu skalieren und zu optimieren. Für bestehende Anwendungen bedeutet dies, dass wir die Komplexität des Originals beibehalten, aber externe Integratoren lediglich einen stabilen, dokumentierten Vertrag (die API) konsumieren müssen. Dies reduziert das technische Risiko bei jeder Erweiterung und macht die Plattform zu einem viel attraktiveren Baustein für Partner und das interne Team. Es ist der notwendige Schritt, um von einem *Monolith* zu einer *Composable Business Platform* zu avancieren. ### Agilität und Unabhängigkeit Wir trennen die Geschäftslogik von der Oberfläche. Dies ist entscheidend, weil die Funktionalität (das *Was*) von der Darstellung (dem *Wie*) getrennt werden muss. Durch die API stellen wir sicher, dass die Kernfunktionen der Plattform (Job-Postings, Netzwerkanbindung) immer verfügbar sind, egal, welche Technologie ein Partner oder ein neues internes Team verwendet. Das erhöht die Agilität exponentiell und macht unser Produkt zu einer echten, frei integrierbaren Infrastruktur.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

rene/BizzFed#2

No description provided.

Rows
Columns