© DrHitch/Shutterstock.com
Microservices-Architektur

2 Domain-Patterns: Bounded Context


Problem

Microservices sollen klein, autonom und miteinander kombinierbar sein. Die Zerlegung der Anwendung in einzelne Komponenten erfolgt dabei vertikal entlang der Fachlichkeit. Aber nach welchen Kriterien erfolgt die Zerlegung der Anwendung, um die Anforderungen, wie klein und autonom, zu erfüllen und die Vorteile von Microservices nicht zu verlieren? Die Strukturierung von Monolithen ist schon schwer, die Strukturierung von Microservices ist noch viel schwerer.

Es gibt eine Menge von bereits bekannten Prinzipien wie das Separation of Concerns [1], das Single Responsibility Principle [2], Gesetze wie Conway‘s Law [3] oder Arbeiten wie die von David Parnas [4], die sich mit der Zerlegung von Anwendungen beschäftigen. Diese Arbeiten gewinnen mit dem Thema Microservices wieder an Bedeutung und Wichtigkeit, denn eine falsche Zerlegung der Anwendung in Microservices kann sehr teuer werden. Ein einfaches Refactoring, wie das bisher in Monolithen möglich war, ist bei Microservices nicht mehr so einfach möglich.

In diesem shortcut können wir nicht alle Aspekte der Zerlegung von Anwendungen in Microservices aufgreifen; wir fokussieren uns daher auf das derzeit am meisten diskutierte Pattern Bounded Context aus dem Domain-driven Design, das von sehr bekannten Architekten wie Eric Evans oder Martin Fowler für die Zerlegung von Anwendungen in Microservices vorgeschlagen wird.

Lösung

Das Domain-driven Design (DDD) unterstützt uns bei der Zerlegung der Anwendung in Microservices. In DDD ist ein Microservice vergleichbar mit einem Bounded Context. Ein Bounded Context entspricht somit einem Microservice.

Microservice := Bounded Context

Listing 2.1: Verhältnis zwischen Microservice und Bounded Context

Abbildung 2.1 zeigt beispielhaft einen Bounded Context. Eine genaue Definition des Bounded Contexts ist in Eric Evans Werk „Domain Driven Design“ [5] zu finden. Stark vereinfacht können wir uns einen Bounded Context wie folgt vorstellen: Eine Organisation besteht aus mehreren Domänen: Shipment, Payment, Supplier.

S:\ENTWICKLERPRESS\Buchproduktion\shortcut\Bild 2_1.png

Abbildung 2.1: Bounded Context

Ein Bounded Context nutzt eine oder mehrere Domänen, um eine bestimmte fachliche Funktion zu liefern, zum Beispiel ERP. Dabei ist die Repräsentation der einzelnen Domänenobjekte, wie etwa Customer, durchaus in jedem Bounded Context unterschiedlich. Mal hat der Customer mehr und mal weniger Attribute, um die benötigten Informationen für den Bounded Context bereitzustellen.

Nach welchen Kriterien schneiden wir aber einen Boun...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang