dieser Ideen würde den Rahmen dieses Buchs sprengen, aber ich werde einen kurzen Überblick über die wichtigsten Ideen geben, die beim Nachdenken über Microservices-Architekturen helfen.
Aggregat
Im DDD ist ein Aggregat ein etwas verwirrendes Konzept, für das es viele verschiedene Definitionen gibt. Handelt es sich einfach um eine beliebige Sammlung von Objekten? Die kleinste Einheit, die ich aus einer Datenbank holen sollte? Bei dem Modell, das bei mir immer funktioniert hat, ist ein Aggregat eine Repräsentation eines Konzepts aus der realen Domäne – stellen Sie sich so etwas vor wie eine Bestellung, eine Rechnung, ein Lagerteil oder Ähnliches. Aggregate haben normalerweise einen Lebenszyklus, der es ermöglicht, dass sie als Zustandsmaschine implementiert werden. Wir wollen Aggregate als in sich geschlossene Einheiten behandeln und sichergehen, dass der Code, der sich um die Zustandsübergänge eines Aggregats kümmert, mit dem Zustand selbst in einer Gruppe zusammenbleibt.
Denken wir über Aggregate und Microservices nach, kümmert sich ein einzelner Microservice um den Lebenszyklus und die Datenspeicherung eines oder mehrerer Typen von Aggregaten. Möchte die Funktionalität in einem anderen Service eines dieser Aggregate ändern, muss sie entweder direkt eine Änderung an diesem Aggregat anfordern oder das Aggregat selbst auf andere Dinge im System reagieren lassen, um seinen eigenen Zustandsübergang auszulösen – Beispiele dafür sehen Sie in Abbildung 1-17.
Entscheidend ist hier, zu verstehen, dass ein Aggregat es auch ablehnen kann, wenn ein Außenstehender einen Zustandsübergang anfordert. Sie werden Ihre Aggregate idealerweise so implementieren, dass illegale Zustandsübergänge nicht möglich sind.
Aggregate können Beziehungen zu anderen Aggregaten haben. In Abbildung 1-18 gibt es ein Customer-Aggregat, das mit einer oder mehreren Orders verbunden ist. Wir haben uns entschieden, Customer und Order als getrennte Aggregate zu modellieren, die von unterschiedlichen Services betreut werden könnten.
Es gibt viele Möglichkeiten, ein System in Aggregate aufzuteilen, wobei manche Entscheidungen sehr subjektiv sein können. So kann es aus Performancegründen oder zur leichteren Implementierung angebracht sein, Aggregate nach einiger Zeit neu zu formen. Zu Beginn schlage ich aber vor, Implementierungsüberlegungen nachrangig zu betrachten und das Gedankenmodell der Systemanwender als die Richtschnur für das erste Design anzunehmen, bis andere Faktoren ins Spiel kommen. In Kapitel 2 werde ich Event Storming als gemeinschaftliche Übung vorstellen, die dabei hilft, diese Domänenmodelle mit der Hilfe von Kollegen zu bilden, die gerade keine Entwickler sind.
Abbildung 1-17: Verschiedene Möglichkeiten, wie unser Payment-Service einen »Paid«-Übergang in unserem Invoice-Aggregat auslösen kann
Abbildung 1-18: Ein Customer-Aggregat kann mit null oder mehr Order-Aggregaten verbunden sein.
Kontextgrenzen
Eine Kontextgrenze (Bounded Context) steht im Allgemeinen für eine größere organisatorische Grenze in einer Organisation. Im Rahmen dieser Grenze müssen explizite Verantwortlichkeiten festgelegt werden. Das ist vielleicht etwas unklar, daher schauen wir uns ein weiteres Beispiel an.
Bei Music Corp ist im Lager extrem viel los – Bestellungen werden verschickt (und Rückläufer verarbeitet), Wareneingänge eingeräumt, es gibt Gabelstaplerrennen und so weiter. Die Finanzabteilung im Bürotrakt hingegen hat vielleicht weniger Spaß, aber sie ist in unserer Organisation genauso wichtig – sie kümmert sich um die Gehaltsabrechnungen, bezahlt Lieferungen und so weiter.
Kontextgrenzen verbergen Implementierungsdetails. Es gibt interne Angelegenheiten – zum Beispiel ist die Marke der Gabelstapler für jeden außerhalb des Lagers eher uninteressant. Diese internen Angelegenheiten sollten vor der Außenwelt verborgen werden – sie muss diese nicht wissen und sollte sich auch nicht darum kümmern.
Aus Implementierungssicht enthalten Kontextgrenzen eines oder mehrere Aggregate. Manche Aggregate können über die Kontextgrenze hinaus bereitgestellt werden, während andere intern verborgen bleiben. Wie bei Aggregaten können Kontextgrenzen Beziehungen zu anderen Kontextgrenzen haben – abgebildet auf Services, werden diese Abhängigkeiten zu Inter-Service-Abhängigkeiten.
Aggregate und Kontextgrenzen auf Microservices abbilden
Sowohl die Aggregate wie auch die Kontextgrenzen liefern uns Kohäsionseinheiten mit wohldefinierten Schnittstellen zum größeren System. Das Aggregat ist eine in sich abgeschlossene Zustandsmaschine, die sich auf ein einzelnes Domänenkonzept in unserem System konzentriert, während die Kontextgrenze eine Sammlung zusammengehöriger Aggregate repräsentiert, ebenfalls wieder mit einer expliziten Schnittstelle nach draußen.
Beides kann daher als Servicegrenzen gut funktionieren. Wie schon erwähnt, sollten Sie zu Beginn die Anzahl an Services, mit denen Sie arbeiten, klein halten. Daher wäre es vermutlich angebracht, Services anzustreben, die ganze Kontextgrenzen darstellen. Wenn Sie dann Fuß gefasst haben und sich entschließen, diese Services in kleinere Services zu unterteilen, versuchen Sie, sie entlang der Aggregatsgrenzen aufzuteilen.
Wenn Sie sich dazu entscheiden, einen Service, der eine ganze Kontextgrenze modelliert, später in kleinere Services aufzuteilen, besteht ein Trick darin, diese Entscheidung trotzdem vor der Außenwelt zu verbergen – etwa indem Sie eine grobkörnigere API für Konsumenten anbieten. Die Entscheidung, einen Service in kleinere Teile aufzutrennen, ist unbestreitbar eine Implementierungsentscheidung, daher können wir das auch verbergen!
Weitere Quellen
Eine umfassende Begutachtung des Domain-Driven Design ist lohnenswert, sprengt aber den Rahmen dieses Buchs. Wollen Sie sich mehr damit befassen, schlage ich vor, entweder Eric Evans Domain-Driven Design oder Vaughn Vernons Domain-Driven Design Distilled zu lesen.12
Zusammenfassung
Wir haben in diesem Kapitel darüber gesprochen, dass es sich bei Microservices um unabhängig deploybare Services handelt, die rund um eine Businessdomäne modelliert sind. Sie kommunizieren untereinander über Netzwerke. Wir haben die Prinzipien des Information Hiding zusammen mit dem Domain-Driven Design vorgestellt, um Services mit stabilen Grenzen zu schaffen, an denen leichter unabhängig voneinander gearbeitet werden kann, und wir tun, was wir können, um die vielen Formen der Kopplung zu reduzieren.
Auch haben wir uns kurz angeschaut, woher diese Konzepte kamen, und sogar Zeit dafür gefunden, einen kleinen Teil der vielen Vorarbeiten zu betrachten, auf denen sie aufbauen. Dann haben wir uns kurz damit befasst, welche Herausforderungen es bei Microservices-Architekturen gibt. Das ist ein Thema, das ich im nächsten Kapitel genauer behandeln werden. Dort geht es auch darum, wie man einen Übergang zu einer Microservices-Architektur plant – und Sie erhalten Ratschläge, die Ihnen bei der Entscheidung helfen, ob eine Microservices-Architektur für Sie überhaupt das Richtige ist.
Конец ознакомительного фрагмента.
Текст