@Deprecated Deadlock

Beim Aktualisieren von Bibliotheken finden sich immer wieder Methoden, die nicht mehr zeitgemäß sind. Denn häufig ermöglichen neuere Ansätze kompakteren, einfacheren oder eleganteren Code. Um den Nutzern der Bibliothek das Leben nicht zu erschweren, werden solche Methoden als veraltet (@Deprecated) markiert. Damit beginnt eine Gnadenfrist, in der die Nutzer ihren eigenen Code auf die neuen Alternativen umbauen müssen. Diese Frist endet, wenn die Entwickler der Bibliothek die veralteten Methoden löscht.

JDBC Streams

In mancher Java Anwendung befinden sich Legacy Code Einschlüsse um JDBC Anfragen, die nicht mehr zeitgemäß erscheinen. Häufig wünscht sich der Entwickler, den recht plumpen Code durch eine elegante Stream Variante zu ersetzen. In dem Beitrag JPA Tabellen mit reservierten Nummernkreisen wurden IDs aus einer Tabelle ausgelesen, um den größten gefundenen Wert als Basis für zukünftige IDs zu nutzen. Der ursprüngliche Code arbeitet mit einer while-Schleife, die über ein ResultSet iteriert.

Fehlerbehandlung aus der Hölle

Die Fehlerbehandlung in der Programmiersprache Java folgt einigen einfachen aber mächtigen Mustern. Dennoch zeigt sich immer wieder die Tendenz, auf erschreckende Weise davon abzuweichen.

Smaugs Einöde

Manche Probleme werden von den Kollegen nur erkannt, wenn wir für sie drastische Vergleiche entwerfen. Ohne die Bilder einer anderen Gefahr vor dem inneren Auge, werden organisatorische Defizite häufig mit einem Achselzucken hingenommen. Wer kennt ihn nicht Smaug den Drachen? In meiner Jugend wussten tatsächlich nur die Liebhaber von Sagen und phantastischen Geschichten von ihm, viele von ihnen genauso computerbegeistert wie der Autor. Seitdem der Hobbit nun, in viel zu vielen Teilen, verfilmt wurde, ist die Geschichte von Smaug ins kollektive Gedächtnis gewandert.

Microservice Patterns (Gateway, Anti-Corruption Layer, Strangler, Aggregation, Backend-For-Frontend)

“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.

Microservice Patterns (Domain Events)

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.

Mikroservice Patterns (Database Per Service)

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.

Der Mikrokosmos und Makrokosmos der Microservices

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.

Implementierungen inkrementell verändern mit dem Branch By Abstraction Pattern

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.

Service Limitierung mit Bucket4J

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.