Ein Beitrag bei heise Developer untersucht, warum ein statisches Domain-Modell nicht automatisch zu sinnvollen Microservices führt. Entscheidend sind neben den Geschäftsobjekten auch die Abläufe, die Nutzung und die Lastverteilung eines Systems.
Microservices sollen unabhängig produktiv geschaltet werden können und über lose gekoppelte Schnittstellen miteinander kommunizieren. Der Artikel verknüpft diesen Ansatz mit Domain-Driven Design und zeigt anhand von Einkauf, Zahlungsverkehr und Logistik, wie unterschiedliche fachliche Kontexte zu unterschiedlichen Servicegrenzen führen.
Nutzung und Last beeinflussen die Servicegrenze
Im Beispiel eines Einkaufsprozesses lassen sich Stammdaten, Ausschreibungen, Angebote und Vergaben zunächst als zusammenhängende Geschäftsobjekte betrachten. Im Betrieb greifen jedoch verschiedene Nutzergruppen unterschiedlich auf diese Bereiche zu. Viele Lieferanten erzeugen beispielsweise eine andere Last als einzelne Einkäufer, die Angebote prüfen und Vergaben auslösen.
Aus diesen Zugriffsmustern können zusätzliche Kontextgrenzen entstehen. Für ein Spielestudio oder ein technisches Team ist der Befund auch bei Online-Diensten relevant, wenn Matchmaking, Inventar, Abrechnung oder Telemetrie nicht nur fachlich, sondern auch nach Zugriffslast und Betriebsablauf getrennt werden müssen. Die Trennung darf nicht allein aus der Klassenstruktur eines statischen Modells abgeleitet werden.
Geschäftsprozesse zeigen versteckte Abhängigkeiten
Bei Kreditkartentransaktionen trennt der Beitrag Transaktionen und Aggregationen. Die Transaktionsverarbeitung benötigt deutlich mehr Zugriffe als spätere Auswertungen. Zusätzlich entstehen Grenzen durch die beteiligten Organisationen, etwa wenn ein Zahlungsdienstleister Rechnungen erstellt und eine Bank Auszahlungsdateien verarbeitet.
Das Logistikbeispiel führt zu einer ähnlichen Beobachtung. Touren, Fahrerzuordnung, Monitoring, Bewertung und Reporting können technisch zusammengehören, werden bei Kunden aber möglicherweise getrennt eingesetzt. Die passende Aufteilung hängt deshalb auch davon ab, wie eine Anwendung betrieben, angeboten und weiterentwickelt wird.
Die Analyse ergänzt den früheren Bericht zur GitHub Checks API, die Build- und Testrückmeldungen direkt in Pull Requests sichtbar machte. Beide Themen betreffen technische Teams, die ihre Entwicklungs- und Betriebsabläufe anhand konkreter Schnittstellen und Rückmeldungen strukturieren.