© Palto/Shutterstock.com
Entwickler Magazin
Von Monolithen zu Microservices

DDD als Schlüssel zum Erfolg

In vielen Unternehmen sind sie noch zu finden: monolithische Legacy-Systeme, die über Jahrzehnte gewachsen sind. Nach und nach stellen IT-Abteilungen die Altsysteme auf Microservices um. Dabei eignet sich nicht jedes System zur Migration, und auch bei der Integration bestehender Datenbanken gilt es einiges zu beachten.

Michael Stoye, Sebastian Bindick


Der Umstieg auf Microservices bringt viele Vorteile mit sich. Eines der Grundprinzipien in der Softwareentwicklung ist die Modularisierung. Bereits 1972 stellte David Parnas das Prinzip des „Information Hiding“ vor [1]. Die Grundidee hinter Modularisierung ist, ein Softwaresystem in Module mit begrenzter Komplexität und klaren Schnittstellen zu zerlegen. Die interne Businesslogik der Module bleibt dem Nutzer dabei verborgen. Dieses Prinzip der Modularisierung treiben Microservices auf die Spitze, indem sie jedes Element des Funktionsumfangs in einem eigenen Service auslagern (Abb. 1).

Abb. 1: Die Grundidee von Microservices

Microservices-Architekturen zeichnen sich durch fünf Kerneigenschaften aus:

Bounded Context: Der Funktionsumfang einer Anwendung wird in fachlich abgrenzbare Kontexte (Bounded Context) geschnitten. Gemäß dem Prinzip „Do one thing and do it well“ hat jeder Kontext genau eine funktionale Aufgabe. Aus technischer Sicht wird je Kontext ein Service implementiert, der sowohl für die Datenhaltung als auch für die Businesslogik und das User Interface verantwortlich ist. Ein Entwicklungsteam, bestehend aus maximal zehn Personen, setzt jeweils einen Service um.

Lose Kopplung: Die Kopplung von Microservices erfolgt lose und anders als bei konventionellen Modularisierungstechniken, bei denen Funktionen in Bibliotheken und Klassen, die im selben Prozess laufen, ausgelagert werden. Microservices hingegen werden separat in eigenen Prozessen ausgeführt und über das Netzwerk, zum Beispiel auf Basis von RESTful HTTP, miteinander gekoppelt.

Unabhängige Deploybarkeit: Entwicklungsteams können Services weitestgehend unabhängig voneinander in die Produktion überführen. Voraussetzung dafür ist ein guter fachlicher Schnitt der Anwendung. Außerdem unterstützen leichtgewichtige Virtualisierungstechniken wie Docker die einfache Bereitstellung der Services. Jedes Team arbeitet innerhalb einer eigenen Deployment-Pipeline (Continuous Integration/Continuous Development) und hat somit den Build-Prozess und die Absicherung des Service in der eigenen Hand. Lediglich einige wenige Integrationstests müssen übergreifend durchgeführt werden.

Unabhängige Technologiestacks: Da die Integration der Services in ein Gesamtsystem lose gekoppelt über das Netzwerk erfolgt, ist ein gemeinsamer Technologiestack nicht erforderlich. Jeder Service lässt sich mit einer eigenen Technologie wie etwa Programmiersprache, Frameworks, Datenbank, Betriebssystem oder Laufzeitumgebung umsetzen. Die T...

Entwickler Magazin
Von Monolithen zu Microservices

DDD als Schlüssel zum Erfolg

In vielen Unternehmen sind sie noch zu finden: monolithische Legacy-Systeme, die über Jahrzehnte gewachsen sind. Nach und nach stellen IT-Abteilungen die Altsysteme auf Microservices um. Dabei eignet sich nicht jedes System zur Migration, und auch bei der Integration bestehender Datenbanken gilt es einiges zu beachten.

Michael Stoye, Sebastian Bindick


Der Umstieg auf Microservices bringt viele Vorteile mit sich. Eines der Grundprinzipien in der Softwareentwicklung ist die Modularisierung. Bereits 1972 stellte David Parnas das Prinzip des „Information Hiding“ vor [1]. Die Grundidee hinter Modularisierung ist, ein Softwaresystem in Module mit begrenzter Komplexität und klaren Schnittstellen zu zerlegen. Die interne Businesslogik der Module bleibt dem Nutzer dabei verborgen. Dieses Prinzip der Modularisierung treiben Microservices auf die Spitze, indem sie jedes Element des Funktionsumfangs in einem eigenen Service auslagern (Abb. 1).

Abb. 1: Die Grundidee von Microservices

Microservices-Architekturen zeichnen sich durch fünf Kerneigenschaften aus:

Bounded Context: Der Funktionsumfang einer Anwendung wird in fachlich abgrenzbare Kontexte (Bounded Context) geschnitten. Gemäß dem Prinzip „Do one thing and do it well“ hat jeder Kontext genau eine funktionale Aufgabe. Aus technischer Sicht wird je Kontext ein Service implementiert, der sowohl für die Datenhaltung als auch für die Businesslogik und das User Interface verantwortlich ist. Ein Entwicklungsteam, bestehend aus maximal zehn Personen, setzt jeweils einen Service um.

Lose Kopplung: Die Kopplung von Microservices erfolgt lose und anders als bei konventionellen Modularisierungstechniken, bei denen Funktionen in Bibliotheken und Klassen, die im selben Prozess laufen, ausgelagert werden. Microservices hingegen werden separat in eigenen Prozessen ausgeführt und über das Netzwerk, zum Beispiel auf Basis von RESTful HTTP, miteinander gekoppelt.

Unabhängige Deploybarkeit: Entwicklungsteams können Services weitestgehend unabhängig voneinander in die Produktion überführen. Voraussetzung dafür ist ein guter fachlicher Schnitt der Anwendung. Außerdem unterstützen leichtgewichtige Virtualisierungstechniken wie Docker die einfache Bereitstellung der Services. Jedes Team arbeitet innerhalb einer eigenen Deployment-Pipeline (Continuous Integration/Continuous Development) und hat somit den Build-Prozess und die Absicherung des Service in der eigenen Hand. Lediglich einige wenige Integrationstests müssen übergreifend durchgeführt werden.

Unabhängige Technologiestacks: Da die Integration der Services in ein Gesamtsystem lose gekoppelt über das Netzwerk erfolgt, ist ein gemeinsamer Technologiestack nicht erforderlich. Jeder Service lässt sich mit einer eigenen Technologie wie etwa Programmiersprache, Frameworks, Datenbank, Betriebssystem oder Laufzeitumgebung umsetzen. Die T...

Neugierig geworden?


    
Loading...

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