Microservices
Eins der vielen Buzz-Wörter in der Software-Entwicklung ist Microservices. Es ist ein möglicher Weg, eine große Anwendung zu unterteilen in voneinander unabhängige Module. Im besten Fall könnten dann unterschiedliche Teams an diesen Teilen arbeiten, ihre präferierte Programmiersprache verwenden und nach eigenem Ermessen neue Versionen herausgeben.
Das grundlegende Problem ist die Software-Entwicklung im Team. Denn als einzelne Entwicklerin hat man naturgemäß auch den Überblick und den Laden im Griff. Aber sobald die Anwendung größer wird und mehrere Menschen am gleichen Thema arbeiten, verschwindet der Gesamtüberblick, bzw. verteilt sich auf viele Köpfe. Also muss man ohnehin Module bilden, welche ein Problem lösen und hoffentlich gut mit anderen Modulen zusammenarbeiten. Die spannende Frage ist natürlich, wie man geschickt portioniert. Denn wenn diese Grob-Unterteilung grundsätzlich nicht funktioniert, helfen Microservices auch nicht weiter.
Microservices won’t fix your modularization.
Gut gestaltete Microservices
- sind lose gekoppelt,
- erlauben das Ändern eines Moduls und
- können individuell bereitgestellt werden.
Domänengetriebener Entwurf
Erst mit gut geschnittenen Teilsystemen machen Microservices Sinn. Teilsysteme oder Domänen sind frei veränderbar, solange die Erwartungen der anderen Module erfüllt sind. Andere Module nutzen alles Wissen, was bereitgestellt wird. Deshalb gilt es, Informationen zu verstecken, so viel wie möglich und insbesondere die Implementierungsdetails. Damit ist das betreffende Teilsystem leichter veränderbar.
Aus der Objektorientierung bekannt sind Klassen. Schon diese enthalten Instanzvariablen und öffentliche Methoden zur Manipulation der Daten.
Bounded Context
Ein Bounded Context funktioniert ähnlich wie Klassen, aber grobgranularer. Er ist nicht daten-zentriert.
Eine mögliche Implementierung für einen Bounded Context wäre jetzt ein Microservice. Aber genau so gut könnte man das mit einer Bibliothek lösen.