Identifizieren von Domänenmodellgrenzen für jeden Microservice

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Das Ziel beim Identifizieren von Modellgrenzen und -größe für jeden Microservice ist nicht die möglichst präzise Trennung, obwohl Sie bei Möglichkeit zu kleinen Microservices neigen sollten. Stattdessen sollte Ihr Ziel darin stehen, die sinnvollste Trennung zu erreichen, die von Ihrem Domänenwissen geleitet wird. Der Schwerpunkt liegt nicht auf der Größe, sondern auf den Geschäftsfunktionen. Wenn für einen bestimmten Bereich der Anwendung ein klarer Zusammenhalt erforderlich ist, der auf einer hohen Anzahl von Abhängigkeiten basiert, bedeutet dies auch, dass ein einzelner Mikroservice benötigt wird. Der Zusammenhalt ist eine Möglichkeit, zu identifizieren, wie Mikroservices auseinandergebrochen oder gruppiert werden. Schließlich sollten Sie, während Sie mehr Wissen über die Domäne erhalten, die Größe Ihres Mikroservice iterativ anpassen. Das Auffinden der richtigen Größe ist kein einmaliger Vorgang.

Sam Newman, ein anerkannter Förderer von Microservices und Autor des Buchs Building Microservices, hebt hervor, dass Sie Ihre Microservices basierend auf dem Bounded Context (BC)-Muster (Teil des domänengesteuerten Designs) entwerfen sollten, wie zuvor eingeführt. Manchmal kann ein BC aus mehreren physischen Diensten bestehen, aber nicht umgekehrt.

Ein Domänenmodell mit bestimmten Domänenentitäten gilt innerhalb eines konkreten BC oder Microservice. Ein BC schränkt die Anwendbarkeit eines Domänenmodells ab und gibt Entwicklern ein klares und gemeinsames Verständnis darüber, was zusammengehörig sein muss und was unabhängig entwickelt werden kann. Dies sind die gleichen Ziele für Microservices.

Ein weiteres Tool, das Ihre Designauswahl informiert, ist conway's Gesetz, das besagt, dass eine Anwendung die sozialen Grenzen der Organisation widerspiegelt, die sie produziert hat. Manchmal verhält es sich jedoch genau umgekehrt: Die Organisation eines Unternehmens wird durch die Software bestimmt. Möglicherweise müssen Sie das Gesetz von Conway umkehren und die Grenzen so aufbauen, wie das Unternehmen organisiert werden soll, und sich auf die Unternehmensberatung stützen.

Um gebundene Kontexte zu identifizieren, können Sie ein DDD-Muster verwenden, das als Kontextzuordnungsmuster bezeichnet wird. Mit der Kontextzuordnung identifizieren Sie die verschiedenen Kontexte in der Anwendung und deren Grenzen. Es ist üblich, für jedes kleine Subsystem einen anderen Kontext und eine andere Grenze zu haben. Die Kontextkarte ist eine Möglichkeit, diese Grenzen zwischen Domänen zu definieren und explizit zu machen. Ein BC ist autonom und enthält die Details einer einzelnen Domäne -details wie die Domänenentitäten und definiert Integrationsverträge mit anderen BCs. Dies ähnelt der Definition eines Microservice: Es ist autonom, implementiert bestimmte Domänenfunktionen und muss Schnittstellen bereitstellen. Aus diesem Grund sind Kontextzuordnung und das Bounded Context-Muster gute Ansätze zum Identifizieren der Domänenmodellgrenzen Ihrer Microservices.

Beim Entwerfen einer großen Anwendung sehen Sie, wie sein Domänenmodell fragmentiert werden kann – ein Domänenexperte aus der Katalogdomäne beschreibt Entitäten in Katalog- und Bestandsdomänen anders als ein Versanddomänenexperte. Oder die Benutzerdomänenentität unterscheidet sich möglicherweise in der Größe und Anzahl der Attribute bei einem CRM-Experten, der jedes Detail über den Kunden speichern möchte, als für einen Bestelldomänenexperten, der nur Teildaten über den Kunden benötigt. Es ist sehr schwer, alle Domänenbegriffe in allen Domänen zu unterscheiden, die sich auf eine große Anwendung beziehen. Aber das Wichtigste ist, dass Sie nicht versuchen sollten, die Begriffe zu vereinheitlichen. Akzeptieren Sie stattdessen die Unterschiede und Fülle der einzelnen Domänen. Wenn Sie versuchen, eine einheitliche Datenbank für die gesamte Anwendung zu haben, werden die Versuche eines einheitlichen Vokabulars unpassend wirken und bei den verschiedenen Fachgebietsexpert*innen nicht gut ankommen. Daher helfen Ihnen BCs (implementiert als Microservices), zu klären, wo Sie bestimmte Domänenbegriffe verwenden können und wo Sie das System teilen und zusätzliche BCs mit verschiedenen Domänen erstellen müssen.

Sie werden wissen, dass Sie die richtigen Grenzen und Größen jedes BC- und Domänenmodells erhalten haben, wenn Sie nur wenige starke Beziehungen zwischen Domänenmodellen haben, und Sie müssen bei typischen Anwendungsvorgängen normalerweise keine Informationen aus mehreren Domänenmodellen zusammenführen.

Vielleicht ist die beste Antwort auf die Frage, wie groß ein Domänenmodell für jeden Microservice sein sollte: Es sollte ein autonomes BC haben, so isoliert wie möglich, damit Sie arbeiten können, ohne ständig zu anderen Kontexten wechseln zu müssen (andere Microservice-Modelle). In Abbildung 4-10 können Sie sehen, wie mehrere Microservices (mehrere BCs) jeweils über ein eigenes Modell verfügen und wie ihre Entitäten definiert werden können, je nach den spezifischen Anforderungen für jede der identifizierten Domänen in Ihrer Anwendung.

Abbildung 4-10. Identifizieren von Entitäten und Mikroservicemodellgrenzen

Abbildung 4-10 veranschaulicht ein Beispielszenario im Zusammenhang mit einem Onlinekonferenzverwaltungssystem. Die gleiche Entität wird abhängig vom gebundenen Kontext als "Users", "Buyers", "Payers" und "Customers" angezeigt. Sie haben mehrere BCs identifiziert, die als Microservices implementiert werden können, basierend auf Domänen, die Domänenexperten für Sie definiert haben. Wie Sie sehen können, gibt es Entitäten, die nur in einem einzigen Microservice-Modell vorhanden sind, z. B. Zahlungen im Payment Microservice. Dies wird leicht zu implementieren sein.

Möglicherweise verfügen Sie jedoch auch über Entitäten, die über eine andere Form verfügen, aber die gleiche Identität über mehrere Domänenmodelle hinweg von den mehreren Microservices aufweisen. Beispielsweise wird die Benutzerentität im Konferenzverwaltungs-Microservice identifiziert. Derselbe Benutzer, mit derselben Identität, wird im Bestell-Microservice als „Käufer“ bezeichnet, im Zahlungs-Microservice als „Zahler“ und sogar im Kundenservice-Microservice als „Kunde“. Dies liegt daran, dass ein Benutzer je nach der allgegenwärtigen Sprache , die jeder Domänenexperte verwendet, auch mit unterschiedlichen Attributen eine andere Perspektive hat. Die Benutzerentität im Microservice-Modell namens Conferences Management verfügt möglicherweise über die meisten persönlichen Datenattribute. In der Rolle von Payer im Zahlungs-Microservice oder als Kunde im Kundendienst-Microservice benötigt derselbe Benutzer möglicherweise nicht dieselbe Liste von Attributen.

Ein ähnlicher Ansatz ist in Abbildung 4-11 dargestellt.

Abbildung 4-11. Zerlegen herkömmlicher Datenmodelle in mehrere Domänenmodelle

Wenn Sie ein herkömmliches Datenmodell zwischen gebundenen Kontexten dekompilieren, können Sie über unterschiedliche Entitäten verfügen, die dieselbe Identität gemeinsam nutzen (ein Käufer ist auch ein Benutzer) mit unterschiedlichen Attributen in jedem gebundenen Kontext. Sie können sehen, wie der Benutzer im Konferenzverwaltungs-Microservice-Modell als Benutzerentität vorhanden ist und auch in Form der Käuferentität im Pricing microservice vorhanden ist, mit alternativen Attributen oder Details zum Benutzer, wenn es tatsächlich ein Käufer ist. Jeder Microservice oder BC benötigt möglicherweise nicht alle Daten, die sich auf eine Benutzerentität beziehen, nur einen Teil davon, je nachdem, ob das Zu lösende Problem oder der Kontext vorliegt. Im Microservicemodell „Preise“ werden beispielsweise Adresse und Name des Benutzers nicht benötigt, sondern nur die ID (als Identität) und der Status, was sich bei der Preisgestaltung für die Lizenzen pro Käufer auf Rabatte auswirkt.

Die Seat-Entität hat denselben Namen, aber unterschiedliche Attribute in jedem Domänenmodell. Seat hat jedoch eine Identität, die auf derselben ID basiert, genauso wie es bei Benutzer und Käufer der Fall ist.

Grundsätzlich gibt es ein gemeinsames Konzept eines Benutzers, der in mehreren Diensten (Domänen) vorhanden ist, die alle die Identität dieses Benutzers teilen. In jedem Domänenmodell gibt es jedoch möglicherweise zusätzliche oder unterschiedliche Details zur Benutzerentität. Daher muss es eine Möglichkeit geben, eine Benutzerentität von einer Domäne (Microservice) zu einer anderen zuzuordnen.

Es gibt mehrere Vorteile, nicht dieselbe Benutzerentität mit derselben Anzahl von Attributen über Domänen hinweg zu teilen. Ein Vorteil besteht darin, die Duplizierung zu reduzieren, sodass microservice-Modelle keine Daten enthalten, die sie nicht benötigen. Ein weiterer Vorteil besteht darin, einen primären Microservice zu haben, der eine bestimmte Art von Daten pro Entität besitzt, sodass Aktualisierungen und Abfragen für diesen Datentyp nur von diesem Microservice gesteuert werden.

ZurückWeiter