Seite 5: Fazit

Inhaltsverzeichnis

Jede der oben dargestellten Optionen hat ihre Berechtigung. Ihr Einsatz hängt stark von den Gegebenheiten ab. Den geringsten initialen Aufwand hat die erste Variante, da sie durchgeführt wird, bevor man auch nur eine Zeile Code geschrieben hat. Hieraus resultiert die Empfehlung, zunächst einen eher größeren Service zu schreiben. In diesem Service kann man durch eine geschickte Modularisierung ohne größeren Aufwand "Sollbruchstellen" einbauen. Das Zerlegen solcher Mikrolithen fällt meist einfacher als das Zusammenlegen von mehreren unabhängigen Komponenten. Aber bitte aufpassen: Spätestens an Teamgrenzen sollte auch eine Komponentengrenze im Code vorhanden sein.

Sollte eine Vergrößerung nicht möglich sein, kann man die anderen Varianten in Betracht ziehen. Hat man sehr eigenständige Services in einer API, sind die Möglichkeiten in Abschnitt 3 vielleicht praktikabel. Hat man größere Abhängigkeiten zwischen den Services, eigene Lebenszyklen von API und Backend-Services oder das Bedürfnis, mehrere APIs mit den gleichen Services zur Verfügung zu stellen, würde man zur zweiten Möglichkeit greifen. Die APIs wirken dadurch eher aus einem Guss und können mehr und schneller auf Kundenbedürfnisse eingehen, bringen aber die oben beschriebenen Nachteile mit.

Jörg Adler
ist zur Zeit bei der Mercateo AG als Softwareentwickler tätig. Aktuelle Schwerpunkte sind REST-Schnittstellen und interne Systeme. (bbo)