Thoughts on agile software development
“Beziehungen bleiben bestehen aber Bedürfnisse ändern sich”. So oder so ähnlich heißt es in einer schlüpfrigen Fernsehwerbung zu später Stunde. Bei Microservices finden sich aber tatsächlich immer wieder Situationen, bei denen zwei Microservices besser harmonieren, wenn ein dritter involviert ist.
Wie auch der vorherigen Beitrag handelt dieser über Microservices als Architekturkonzept und die dort verwendeten Design Pattern. Bei dem Microservice Pattern Domain Events handelt es sich um die Nutzung von fachlichen Ereignisse aus dem Bereich Domain-Driven Design. Die Microservices kommunizieren also nicht nur über direkten Nachrichtenaustausch mit ihnen bekannten Services, sondern sie signalisieren auch Änderungen an entkoppelte, ihnen unbekannte Services.
Mikroservices stellen ein eigenes Architekturkonzept dar, mit denen Anwendungen dezentral und entkoppelt entwickelt und betrieben werden können. Eine große Anzahl von Design Pattern macht es den Entwicklern dabei einfach, gute Architekturen zu erstellen. Die Mikroservices Architektur wirkt sich jedoch nicht nur auf die Software aus, sondern bietet auch viel Potenzial um die Arbeit der Teams zu verbessern. Wie dies im speziellen aussehen kann soll an dem sehr grundlegenden Pattern Database Per Service dargestellt werden.
Ein großes Missverständnis bei der Verwendung von Microservices, ist die Annahme, es wären einfach nur sehr kleine Services. Diese Herangehensweise führt zwar schnell zu beträchtlichen Erfolgen, sie fördert aber mittel- und langfristig Fehler in ihrer Betrachtung, Verwendung und Entwicklung.
Um eine bestehende Software Komponente umzubauen erstellt der Software Entwickler in der Regel einen Feature-Branch. In diesem Feature-Branch werden alle notwendigen Änderungen vorgenommen und das Ergebnis zurück in den Haupt-Branch gemerged. Unangenehm wird dieses Vorgehen, wenn die Änderungen aufwendig und langwierig sind. Denn je länger die Änderungen dauern, desto schwieriger wird es, die Änderungen in den Haupt-Branch zu integrieren. Dies liegt weniger an den Änderungen im Feature-Branch, sondern an den zwischenzeitlichen Änderungen am Haupt-Branch, der durch andere Feature-Branches unaufhörlich verändert wird. Eine Möglichkeit der Merge-Hölle von langlebigen Branches zu entgehen ist das Branch By Abstraction Pattern.
REST Services können nur eine gewisse Anzahl von Anfragen innerhalb eines Zeit Fensters verarbeiten. Werden zu viele Anfragen gestellt, dann gerät der Service unter Last und reagiert sehr langsam oder gar nicht mehr. Zusätzliche Anfragen, die ein vorgegebenes Limit übersteigen, sollten daher vom Service abgelehnt werden.
Kostspielige Initialisierungen von lokalen Variablen müssen verzögert vorgenommen werden . Dabei werden häufig If-Konstrukte verwenden, die der Lesbarkeit des bestehenden Codes schaden.
Bei jedem Beitrag zum Visitor Pattern habe ich die Vermutung, es wird wohl der letzte zum Thema sein. Aber nur knapp drei Monate nach “Kalenderspielereien mit Java – iCalendar” folgt schon ein neuer Beitrag zu diesem Design-Pattern.
In den Beiträgen REST in Peace und REST heißt HATEOAS wurde schon auf die Möglichkeiten des HATEOAS Patterns hingewiesen. Die Verlinkung von Resourcen nutzen um innerhalb der Client Anwendung das notwendige Wissen um die Server API zu reduzieren, entkoppelt Systeme und vereinfacht die Entwicklung und Wartung. Auch in diesem Beitrag wird es um die Implementierung … Read more
Anti-Pattern sind die schwarzen Schafe unter den Pattern. Sie zeigen eine schlechte Lösung für ein bekanntes Problem. Damit helfen sie aber auf zweierlei Weise, sie warnen vor falschen Entscheidungen und sie helfen bei der Analyse, wenn irgendwas nicht richtig läuft.