Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 31

In einem System, das aus mehreren unabhängigen Services besteht, muss es ganz grundlegend irgendeine Interaktion zwischen den Teilnehmern geben. In einer Microservices-Architektur ist Domänenkopplung das Ergebnis – die Interaktionen zwischen Services modellieren die Interaktionen in unserer realen Domäne. Wollen Sie eine Bestellung tätigen, müssen Sie wissen, welche Dinge im Warenkorb eines Kunden liegen. Möchten Sie ein Produkt ausliefern, müssen Sie wissen, wohin es geliefert werden soll. In unserer Microservices-Architektur können diese Informationen per definitionem in unterschiedlichen Services liegen.

Nehmen wir als konkretes Beispiel unsere Music Corp. Wir haben ein Lager mit Waren. Bestellen Kunden CDs, müssen die Mitarbeiter im Lager wissen, welche CDs ausgewählt und verpackt werden müssen und wohin das Paket gehen soll. Die Informationen über die Bestellung müssen daher mit den Leuten im Lager geteilt werden.

Abbildung 1-13: Eine Bestellung wird an das Lager geschickt, um das Paket zu packen.

Abbildung 1-13 zeigt ein Beispiel dafür: Ein Order-Processing-Service schickt alle Details der Bestellung an den Warehouse-Service, der dann dafür sorgt, dass das gewünschte Produkt verpackt wird. Als Teil dieser Operation nutzt der Warehouse-Service die Customer-ID, um Informationen über den Kunden aus dem eigenständigen Customer-Service abzurufen, sodass wir wissen, wie wir ihn benachrichtigen können, wenn die Bestellung verschickt wird.

In dieser Situation teilen wir die gesamte Bestellung mit dem Lager, was eventuell nicht sinnvoll ist – das Lager muss nur wissen, was zu verpacken ist und wohin es geschickt werden soll. Die Mitarbeitenden dort müssen nicht wissen, wie viel das Produkt kostet (wenn sie eine Rechnung mit in das Paket legen müssen, könnte diese als fertiges PDF mitgegeben werden). Wir könnten sogar Probleme mit Informationen bekommen, die sich möglichst nicht verbreiten sollten – würden wir die vollständige Bestellung verteilen, könnten zum Beispiel auch Kreditkartendaten an Services gehen, die diese gar nicht brauchen.

Abbildung 1-14: Mit einer Pick Instruction reduzieren wir die Menge an Informationen, die wir an den Warehouse-Service schicken.

Stattdessen überlegen wir uns vielleicht ein neues Domänenkonzept mit einer »Pick Instruction«, die nur die Informationen enthält, die das Lagerteam benötigt (siehe Abbildung 1-14). Das ist ein weiteres Beispiel für Information Hiding.

Wir könnten die Kopplung noch weiter verringern, indem wir dafür sorgen, dass der Warehouse-Service überhaupt nichts über den Kunden wissen muss – stattdessen könnten wir alle notwendigen Details über die Pick Instruction mitgeben (siehe Abbildung 1-15).

Abbildung 1-15: Durch das Einfügen weiterer Informationen in die Pick Instruction kann ein Anruf beim Customer-Service vermieden werden.

Damit das funktioniert, muss Order Processing vermutlich irgendwo auf den Customer-Service zugreifen, um diese Pick Instruction überhaupt erzeugen zu können. Aber es ist sehr wahrscheinlich, dass das Order Processing die Kundeninformationen schon aus anderen Gründen benötigt, daher wird das eher kein Problem sein. Dieser Prozess des »Verschickens« einer Pick Instruction beinhaltet einen API-Aufruf vom Order-Processing an den Warehouse-Service.

Eine Alternative könnte darin bestehen, Order Processing eine Art von Event verschicken zu lassen, das das Warehouse empfängt (siehe Abbildung 1-16). Indem wir ein Event feuern, das vom Warehouse aufgenommen wird, drehen wir letztendlich die Abhängigkeiten um. War zuvor das Order Processing davon abhängig, dass der Warehouse-Service dafür sorgen kann, dass die Bestellung verschickt wird, lauscht der Warehouse-Service nun auf Events vom Order-Processing-Service. Beide Ansätze haben ihre Vorteile, und es hängt von einem weitergehenden Verständnis für die Interaktionen zwischen der Order-Processing-Logik und der im Warehouse-Service gekapselten Funktionalität ab, für welchen ich mich entscheiden würde. Dabei kann Domänenmodellierung helfen, was wir uns gleich anschauen werden.

Abbildung 1-16: Ein Event feuern, das der Warehouse-Service empfangen kann und das gerade genug Informationen enthält, damit die Bestellung verpackt und verschickt werden kann

Damit der Warehouse-Service überhaupt etwas tun kann, sind auf jeden Fall irgendwelche Informationen notwendig. Dieser Teil der Domänenkopplung lässt sich nicht vermeiden. Aber indem wir sorgfältig darüber nachdenken, was wir bereitstellen und wie wir das tun, können wir immer noch versuchen, die Kopplung zu minimieren.