Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 11

Eines der Dinge, mit denen die Menschen meiner Beobachtung nach die größten Probleme haben, ist die Vorstellung, dass Microservices keine gemeinsamen Datenbanken nutzen sollten. Möchte ein Service auf Daten zugreifen, die von einem anderen Service gehalten werden, sollte dieser Service den anderen danach fragen. Damit hat der Service die Möglichkeit, zu entscheiden, was bereitgestellt und was verborgen wird. Es erlaubt ihm auch, interne Implementierungsdetails zu verstecken, die sich aus den unterschiedlichsten Gründen ändern können, und einen stabileren öffentlichen Vertrag und damit stabilere Serviceschnittstellen zu ermöglichen. Stabile Schnittstellen zwischen den Services sind sehr wichtig, wenn wir eine unabhängige Deploybarkeit haben wollen – ändert sich die von einem Service bereitgestellte Schnittstelle immer wieder, wird das einen Dominoeffekt verursachen, durch den sich auch andere Services ändern müssen.

Nutzen Sie keine gemeinsamen Datenbanken, sofern Sie das nicht müssen. Und selbst dann versuchen Sie, das so weit wie möglich zu vermeiden. Meiner Meinung nach sind gemeinsame Datenbanken das Schlimmste, was Sie tun können, wenn Sie versuchen, eine unabhängige Deploybarkeit zu erreichen.

Wie wir schon im vorherigen Abschnitt besprochen haben, wollen wir unsere Services als End-to-End-Scheiben der Businessfunktionalität betrachten, die UI, Anwendungslogik und Datenablage sauber kapseln. Denn wir wollen den Aufwand verringern, der notwendig ist, um businessbezogene Funktionalität zu verändern. Das so vorgenommene Kapseln von Daten und Verhalten sorgt für einen engen Zusammenhalt der Businessfunktionalität. Indem wir die Datenbank verbergen, die unseren Service unterstützt, stellen wir auch sicher, dass wir Kopplungen reduzieren. Zu Kopplungen und Zusammenhalt kommen wir gleich noch mal zurück.

Es kann schwer sein, sich das verständlich zu machen, besonders wenn Sie ein bestehendes monolithisches System mit einer riesigen Datenbank vor sich haben. Zum Glück gibt es Kapitel 4, das sich nur darum dreht, von monolithischen Datenbanken wegzukommen.