Ich stecke gerade in einem Projekt fest, wo ich eine eigentlich einfache Datenabfrage über mehrere Services hinweg machen muss. Eigentlich dachte ich, das wäre mit einem gängigen Framework schnell erledigt, aber jetzt grübele ich die ganze Zeit, ob ich den ganzen Ablauf nicht viel eleganter mit einer Query Orchestration lösen könnte. Irgendwie habe ich das Gefühl, ich baue gerade nur viel Boilerplate-Code, der später schwer zu warten ist. Vielleicht übersehe ich auch einen ganz offensichtlichen Ansatz.
Ja das kenne ich gut. Eine einfache Datenabfrage über mehrere Services wird oft zu boilerplate statt zu einem sauberen Fluss. Query Orchestration klingt verlockend weil der Ablauf klarer wirkt, aber ich frage mich ob das wirklich die Komplexität senkt oder nur versteckt?
Aus theoretischer Sicht reduziert Orchestrierung die Abhängigkeiten zwischen Service Interfaces und erlaubt bessere Fehlergrenzen. In der Praxis kommt dann doch noch Verifikation von Verträgen ins Spiel und man muss robuste Retry Strategien definieren statt nur den Weg zu zweit zu gehen.
Vielleicht geht es auch nicht um ein Muster das alles löst sondern darum wie viel Logik man zentral statt dezent verteilt. Wenn man den Fokus verschiebt auf klare Upper Layer Verhalten könnte man auch ohne spezialisierte Engine weiterkommen.
Ich bleibe skeptisch. Eine Orchestrierung kann wie eine Design Falle wirken weil man die echten Begriffe der Domäne aushöhlt und nur noch Abläufe aufzeichnet.
Eine praxisnahe Alternative ist zuerst zu prüfen welche Granularität sinnvoll ist und wo echte Grenzen der Transaktion bestehen. Oft genügt eine robuste Abbildung der Schnittstellen mit kurzen Fallback Pfaden.
Vielleicht hilft es das Thema neu zu rahmen als Frage nach Transparenz statt Eleganz. Was wenn die Frage nicht ist wie orchestrieren sondern wie weit man die Regeln klar macht damit Teams nicht suchen müssen.
Lass uns von einer konkreten Abfrage aus gehen und Schritt für Schritt prüfen wo Boilerplate entsteht, das genügt vielleicht schon um Klarheit zu gewinnen.
