Beim Überschreiten des begrenzten Kontexts, also bei Ereignissen, wird das REST nicht benötigt.

Technische Design-Entscheidungen können sich stark auf die Kommunikationsstruktur von Unternehmen auswirken. Das Gesetz von Conway erklärt: "Jede Organisation, die ein System entwirft (hier weiter gefasst als nur Informationssysteme), wird unweigerlich ein Design produzieren, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist." So verhält es sich auch mit einer Microservices-Architektur. Viele Unternehmen entscheiden sich für die Verwendung von REST für die Kommunikation zwischen begrenzten Kontexten und/oder Diensten. Dabei kann es passieren, dass die Dienste im Bounded Context nun voneinander abhängig werden. Die Abhängigkeit von der Fertigstellung eines Dienstes führt zu kaskadenartigen Ausfällen, wenn ein Dienst ausfällt. Kaskadierende Ausfälle wirken sich auf die Art und Weise aus, wie Organisationen zwischen Teams kommunizieren. Die Teams sind nun aufeinander angewiesen, bevor sie ihren Prozess abschließen können. Die Abhängigkeit zwischen den Teams kann das Unternehmen ernsthaft daran hindern, besser auf die sich schnell ändernden Anforderungen der Kunden zu reagieren; die Unternehmen verstricken sich mehr als früher. Um kaskadierende Ausfälle zu bekämpfen, müssen wir die Kommunikationsstruktur des Unternehmens verfolgen. Wir können dies tun, indem wir Event Storming einsetzen und von den Ereignissen ausgehen.

REST als Kommunikation zwischen begrenzten Kontexten

Unternehmen und Teams, die Microservices entwickeln, verwenden in der Regel Domain Driven Design (DDD). DDD ist ein ganzheitlicher Ansatz für die Softwareentwicklung, bei dem mehrere begrenzte Kontexte mit ihrer allgegenwärtigen Sprache geschaffen werden, um bestimmte Geschäftsprobleme innerhalb eines Modells zu lösen. Das Bounded Context-Muster ist bei der Entwicklung einer Microservices-Architektur am hilfreichsten. Wenn Teams gebundene Kontexte erstellen, suchen sie nach Möglichkeiten, diese voneinander zu entkoppeln. In den letzten Jahren hat REST in der Entwicklergemeinde viel Anklang gefunden. REST ist ein nützliches Architekturmuster, um einen Dienst von seinem Front-End zu entkoppeln. Aus diesem Grund wird REST in der Regel bevorzugt, um die Funktionalität von Diensten offenzulegen.

Die Entscheidung, REST für die Kommunikation zwischen gebundenen Kontexten zu verwenden, kann jedoch schwerwiegende Folgen für die Fähigkeit haben, eigenständig zu bleiben. Wenn ein Prozess beendet ist, müssen Sie dies manchmal anderen gebundenen Kontexten mitteilen. Wenn Sie dafür POST oder PUT verwenden, sind Sie davon abhängig, dass der andere gebundene Kontext reagiert. Wenn dieser gebundene Kontext nicht antwortet, wird der Prozess nicht beendet. Während Ihr Prozess seinen Zweck erfüllt hat, können wir ihn nicht kommunizieren. Also müssen wir entweder etwas entwickeln, das sich an den Anruf erinnert, oder wir haben kaskadierende Ausfälle. Oft müssen Teams, bei denen es zu kaskadierenden Ausfällen kommt, ein Service Level Agreement (SLA) einrichten. Die Teams werden weniger autonom, weil sie bei jeder Änderung diese SLA berücksichtigen müssen.

Ereignisorientierte Microservices-Architektur mit Event Storming

Russ Miles hat in seinem Blogbeitrag bereits erwähnt, dass Sie den Einsatz von Ereignissen in Betracht ziehen sollten. Ereignisse eignen sich besser, um die allgegenwärtige Sprache einer Domäne oder eines Systems zu erfassen. Um Domänenereignisse zu finden, können wir Event Storming verwenden. Event Storming ist eine einfache Form der visuellen Kommunikation, die jeder verstehen kann. Bei dieser Technik, die auf dem Geschichtenerzählen basiert, werden Ereignisse aufgeschrieben und mit orangefarbenen Haftnotizen in eine Zeitleiste eingetragen. Event Storming minimiert Annahmen durch gemeinschaftliches, bewusstes Lernen aus der Perspektive jedes Einzelnen und aus verschiedenen Disziplinen. Es nutzt mehrere Disziplinen, um Geschäftsprobleme auf die effektivste Weise zu lösen. [caption id="attachment_26070" align="aligncenter" width="564"] Copyright Alberto Brandolini[/caption] Dieser Ansatz eignet sich nicht nur für die Entwicklung komplizierter Software, sondern hilft Ihnen auch, Ereignisse zu finden, mit denen Sie Ihre gebundenen Kontexte von anderen entkoppeln können. Sie können diese Ereignisse über einen Message Broker einem anderen Bounded Context zur Verfügung stellen. Sobald Sie ein Ereignis an einen Message Broker übergeben, muss dieser dafür sorgen, dass es zugestellt wird. Sobald die Nachricht an den Message Broker gesendet wurde, ist der Prozess abgeschlossen und kann mit dem nächsten fortgesetzt werden, so dass es keine kaskadierenden Ausfälle mehr gibt. Wenn Sie mehr über DDD oder EventStorming erfahren möchten, sollten Sie mein Whitepaper lesen. Dieser Beitrag wurde auch auf meiner persönlichen Blog-Seite veröffentlicht.