Ich stehe gerade vor einer kniffligen Entscheidung bei einem Projekt und wollte mal hören, wie ihr das handhabt. Wir bauen gerade eine neue Schnittstelle für unsere Kunden, die ziemlich viele verschiedene Datenquellen anbinden muss. Eigentlich dachte ich, wir setzen auf eine einzige, feste API-Strategie, aber je tiefer ich in die Anforderungen einsteige, desto mehr frage ich mich, ob das wirklich der richtige Weg ist. Manchmal fühlt es sich an, als würde ich versuchen, einen eckigen Pfosten in ein rundes Loch zu treiben, besonders wenn ich an die langfristige Wartung denke. Wie geht ihr mit so einer Unsicherheit um, wenn ihr vor der Wahl des Architekturansatzes steht?
Ich frage mich ob eine einzige API Strategie überhaupt die richtige Brücke ist, langfristig wirkt das wie ein eckiger Pfosten im runden Loch und die Wartung schleicht dahinter
Aus meiner Sicht klappt das besser mit einer modularen Adapterlandschaft, klare Verträge, kleine Adapter die sich austauschen lassen und Contract Tests damit niemand am Ende doch die Kompatibilität verliert
Es fühlt sich an als ginge es darum eine einzige Schnittstelle zu bauen, vielleicht geht es aber eher darum mehrere kleine Schnittstellen zu haben die sich zu einer Gesamtlösung ergänzen
Vielleicht missverstehe ich die Prämisse und sehe die Frage nicht als Architekturentscheidung sondern als Rahmen für Governance und Verantwortlichkeit
Was ich neu rahmen würde ist die Lebensdauer der Verträge, Versionierung, Breaking Changes und eine gemeinsame Prämisse statt einem großen Monolithen
Vielleicht klappt es besser zwei API Strategien fuer verschiedene Kundensegmente zu fahren solange beide Prinzipien teilen und niemand glaubt die Kundenseite wird dadurch zu einer Baustelle
