Microservices-Architektur Prinzip #3: kleine begrenzte Kontexte über ein umfassendes Modell

Dieser Beitrag ist Teil einer sechsteiligen Serie über Microservices-Prinzipien. Die anderen Teile sind: Geschäftsfähigkeit, Autonomie, Asynchrone Kommunikation, Beste Technologie und Ein Team.

Microservices sind ein heißes Thema. Um Unternehmen dabei zu helfen, das Beste aus diesem neuen Architekturstil herauszuholen, hat Xebia eine Reihe von Prinzipien definiert, die unserer Meinung nach bei der Implementierung einer Microservice-Architektur angewandt werden sollten. Heute besprechen wir das Domain Driven Design (DDD) Konzept des"Bounded Context" und wie es eine wichtige Rolle bei der Entwicklung von Microservices spielt.

Einer der Diskussionspunkte rund um Microservices, seit der Begriff im Jahr 2013 geprägt wurde, ist die Frage, wie groß (oder besser gesagt, wie klein) ein Microservice sein sollte. Einige Leute, wie Fred George, behaupten, dass Dienste klein sein sollten, vielleicht zwischen 100-1000 Zeilen Code (LoC). LoC ist jedoch ein schlechter Maßstab für die Messung von Software im Allgemeinen und erst recht für die Bestimmung des Umfangs eines Microservice. Bei der Bestimmung des Umfangs unserer Microservices achten wir vielmehr auf die Funktionalität, die ein Dienst bereitstellen muss, und darauf, wie der Dienst mit anderen Diensten zusammenhängt. Unser Ziel ist es, Microservices zu entwerfen, die autonom sind, d.h. eine geringe Kopplung mit anderen Services aufweisen, über gut definierte Schnittstellen verfügen und eine einzige Geschäftsfunktion implementieren, d.h. eine hohe Kohäsion aufweisen. Eine Technik, die hierfür verwendet werden kann, ist das "Context Mapping". Mit dieser Technik identifizieren wir die verschiedenen Kontexte in der IT-Landschaft und deren Grenzen. Die Context Map ist das wichtigste Instrument, um die Grenzen zwischen den Domänen deutlich zu machen. Ein Bounded Context kapselt die Details einer einzelnen Domäne, wie Domänenmodell, Datenmodell, Anwendungsdienste usw., und definiert die Integrationspunkte mit anderen Bounded Contexts/Domänen. Dies passt perfekt zu unserer Definition eines Microservice: autonome, klar definierte Schnittstellen, die eine Geschäftsfunktion implementieren. Das macht Context Mapping (und DDD im Allgemeinen) zu einem ausgezeichneten Werkzeug in der Werkzeugkiste des Architekten für die Identifizierung und den Entwurf von Microservices.Ein weiterer Faktor bei der Dimensionierung unserer Services ist, dass wir Modelle haben möchten, die "in Ihren Kopf passen", damit wir effizient über sie nachdenken können. Die meisten Projekte definieren ein einziges umfassendes Modell, das die gesamte Domäne umfasst, da dies natürlich erscheint und leichter zu pflegen ist, da man sich nicht um die Interaktion zwischen mehreren Modellen kümmern oder von einem Kontext in den anderen übersetzen muss.Für kleine Systeme mag dies zutreffen, aber bei großen Systemen beginnen die Kosten die Vorteile zu überwiegen: Die Pflege eines einzigen Modells erfordert Zentralisierung. Natürlich wird das Modell dazu neigen, zu fragmentieren: Ein Experte aus dem Bereich Buchhaltung wird beispielsweise anders über "Inventar" denken als ein Experte aus dem Bereich Logistik. Es sind viele koordinierte Bemühungen erforderlich, um alle Begriffe in allen Bereichen eindeutig zu definieren. Und schlimmer noch, dieses 'einheitliche Vokabular' ist umständlich und unnatürlich in der Anwendung und wird in den meisten Fällen ignoriert werden. Auch hier helfen begrenzte Kontexte: Sie machen deutlich, wo wir die natürlichen Domänenbegriffe sicher verwenden können und wo wir eine Brücke zu anderen Domänen schlagen müssen. Mit den richtigen Grenzen und Größen unserer begrenzten Kontexte können wir sicherstellen, dass unsere Domänenmodelle "in Ihren Kopf passen" und wir nicht zu oft zwischen den Modellen wechseln müssen. Die beste Antwort auf die Frage, wie groß ein Microservice sein sollte, ist also vielleicht: Er sollte einen gut definierten, begrenzten Kontext haben, der es uns ermöglicht, ohne Rücksicht auf Kontexte zu arbeiten oder zwischen ihnen zu wechseln. [bearbeitet: 3. August 2015 - Präambel hinzugefügt und Zeile " entferntIn den nächsten Tagen werden wir jedes dieser Prinzipien in einer Reihe von Blogbeiträgen ausführlicher behandeln."]