© Liashko/Shutterstock.com
Entwickler Magazin
Alte Prinzipien mit neuen Services

Solide Microservices

Microservices bieten Vorteile bei der Abgrenzung von Funktionalität und Verteilung in einem Netzwerk. Auch in der Vergangenheit existierten schon Prinzipien, die ähnliche Ziele verfolgt haben. Eines dieser Prinzipien ist SOLID. Die Frage lautet also: Wie solide sind Microservices?

Ulf Fildebrandt


Es ist nicht das erste Mal, dass Softwareentwickler vor dem Problem stehen, dass ein System zu groß geworden ist und ein Entwickler es in seiner ganzen Komplexität nicht mehr verstehen kann. Schon im Rahmen der objektorientierten Programmierung haben sich Verfahren und Prinzipien entwickelt, die hierbei helfen sollen. Die Komplexität soll in handhabbare Objekte, sprich Klassen, aufgeteilt werden. Für das Klassendesign haben sich im Laufe der Jahre einige gute Regeln herausgebildet. Eine der bekanntesten Sammlungen nennt sich SOLID. Diese Abkürzung umfasst die folgenden fünf Prinzipien, aus deren Anfangsbuchstaben sich der Name des Prinzips ergibt:

Single Responsibility Principle (SRP): Eine Klasse soll nur eine Aufgabe erfüllen.Open Close Principle (OCP): Eine Klasse soll offen für Erweiterungen sein, aber geschlossen für Modifikationen.Liskov Substition Principle (LSP): Für einen Verwender soll eine Instanz einer Superklasse immer durch seine Subklassen ersetzbar sein.Interface Segregation Principle (ISP): Ein Verwender soll eine Schnittstelle angeboten bekommen, die nur seiner Aufgabe entspricht.Dependency Inversion Principle (DIP): Die Abhängigkeit soll nur von höheren Modulen zu niedrigeren gehen.

Da in den Umgang mit diesen Prinzipien bereits etliche Jahre Erfahrung eingeflossen sind, ist es eine interessante Übung herauszufinden, wie diese Prinzipien beim Design von Microservices helfen können.

Single Responsibility Principle: Eine Aufgabe erfüllen

Das Single-Responsibility-Prinzip besagt, dass eine Klasse nur eine Verantwortung haben darf. Eine Klasse soll eine und nur eine Aufgabe übernehmen. In der Softwareentwicklung haben sich gute Faustregeln entwickelt, um zu prüfen, ob dieses Prinzip wirklich eingehalten wird. Die bekannteste Regel lautet, dass alle Klassen, die mit Manager oder Handler bezeichnet werden, schon dubios sind. Wenn der Entwickler keinen besseren Oberbegriff findet als das Managen von Aufgaben, dann deutet das normalerweise auf eine Klasse hin, die viele Aufgaben zu erledigen hat. Die Konsequenz wiederum ist, dass diese Klasse im Herz des Systems arbeitet und dort auch viel zu tun hat. Das wäre im Prinzip nicht schlecht. Aber im Rahmen der Weiterentwicklung sind solche zentralen Klassen immer schwierig, weil sie den Charakter eines Magneten haben: Jede Änderung am System bedarf einer Änderung in einer beliebigen Klasse und dem Manager oder Handler.

Abb. 1: Ein Microservice für eine Verantwortlichkeit

Auf Microservices angewendet so...

Entwickler Magazin
Alte Prinzipien mit neuen Services

Solide Microservices

Microservices bieten Vorteile bei der Abgrenzung von Funktionalität und Verteilung in einem Netzwerk. Auch in der Vergangenheit existierten schon Prinzipien, die ähnliche Ziele verfolgt haben. Eines dieser Prinzipien ist SOLID. Die Frage lautet also: Wie solide sind Microservices?

Ulf Fildebrandt


Es ist nicht das erste Mal, dass Softwareentwickler vor dem Problem stehen, dass ein System zu groß geworden ist und ein Entwickler es in seiner ganzen Komplexität nicht mehr verstehen kann. Schon im Rahmen der objektorientierten Programmierung haben sich Verfahren und Prinzipien entwickelt, die hierbei helfen sollen. Die Komplexität soll in handhabbare Objekte, sprich Klassen, aufgeteilt werden. Für das Klassendesign haben sich im Laufe der Jahre einige gute Regeln herausgebildet. Eine der bekanntesten Sammlungen nennt sich SOLID. Diese Abkürzung umfasst die folgenden fünf Prinzipien, aus deren Anfangsbuchstaben sich der Name des Prinzips ergibt:

Single Responsibility Principle (SRP): Eine Klasse soll nur eine Aufgabe erfüllen.Open Close Principle (OCP): Eine Klasse soll offen für Erweiterungen sein, aber geschlossen für Modifikationen.Liskov Substition Principle (LSP): Für einen Verwender soll eine Instanz einer Superklasse immer durch seine Subklassen ersetzbar sein.Interface Segregation Principle (ISP): Ein Verwender soll eine Schnittstelle angeboten bekommen, die nur seiner Aufgabe entspricht.Dependency Inversion Principle (DIP): Die Abhängigkeit soll nur von höheren Modulen zu niedrigeren gehen.

Da in den Umgang mit diesen Prinzipien bereits etliche Jahre Erfahrung eingeflossen sind, ist es eine interessante Übung herauszufinden, wie diese Prinzipien beim Design von Microservices helfen können.

Single Responsibility Principle: Eine Aufgabe erfüllen

Das Single-Responsibility-Prinzip besagt, dass eine Klasse nur eine Verantwortung haben darf. Eine Klasse soll eine und nur eine Aufgabe übernehmen. In der Softwareentwicklung haben sich gute Faustregeln entwickelt, um zu prüfen, ob dieses Prinzip wirklich eingehalten wird. Die bekannteste Regel lautet, dass alle Klassen, die mit Manager oder Handler bezeichnet werden, schon dubios sind. Wenn der Entwickler keinen besseren Oberbegriff findet als das Managen von Aufgaben, dann deutet das normalerweise auf eine Klasse hin, die viele Aufgaben zu erledigen hat. Die Konsequenz wiederum ist, dass diese Klasse im Herz des Systems arbeitet und dort auch viel zu tun hat. Das wäre im Prinzip nicht schlecht. Aber im Rahmen der Weiterentwicklung sind solche zentralen Klassen immer schwierig, weil sie den Charakter eines Magneten haben: Jede Änderung am System bedarf einer Änderung in einer beliebigen Klasse und dem Manager oder Handler.

Abb. 1: Ein Microservice für eine Verantwortlichkeit

Auf Microservices angewendet so...

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