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.

Hin und Her mit dem ModelMapper

Häufig müssen Daten aus einer Darstellung in eine andere transformiert werden, weil z.B. eine Kopplung von Datenbank Entitäten an einen REST Controller unerwünscht ist. Im Beitrag Hin und Her mit MapStruct wurde der entsprechende Framework vorgestellt. Neben MapStruct und dem unschönen Selbermachen, gibt es aber noch weitere Alternativen. Eine dieser Alternativen ist das ModelMapper Framework. Auch mit diesem Framework können Instanzen verschiedener Klassen aufeinander abgebildet werden und dabei in gewissen Rahmen manipuliert werden.

JPA Tabellen mit reservierten Nummernkreisen

Nichts ist schlimmer als die Verwendung von alten Datenbanken, die in der Vergangenheit von Hand gepflegt wurden. Häufig ist sehr viel Kreativität gefragt, um auf der existierenden relationalen Struktur, geeignete JPA Entitäten zu erstellen. Ein weiteres Ärgernis, sind dann aber auch die Primärschlüssel der Entität, die in der Vergangenheit nicht durch einen strengen Generator erzeugt wurden, sondern frei gewählt wurden.

Korrekturlesen bei SpringDoc-OpenAPI

Die Bibliothek SpringDoc-OpenAPI ist ein gute Ergänzung für die eigene REST API, um die Endpunkte mit einer Dokumentation zu versehen. Die Bibliothek analysiert die @RestController annotierten Klassen und extrahiert Informationen zu Endpunkten, Parametern, Requests, Responses und Fehlercodes. Die gefundenen Informationen werden als OpenAPI Dokumentation im YAML oder JSON Format ausgegeben. Das klingt sehr gut, nur leider funktioniert es nicht ohne zusätzliche Eingriffe der Entwickler.

Der Rete Algorithmus (3)

Im zweiten Beitrag zum Rete Algorithmus wurde eine erste einfache Implementierung vorgestellt. Schon bei der Umsetzung zeigte sich jedoch, dass diverse Details anders gelöst werden sollten. Es passiert recht häufig, dass sich eine zu enge Anlehnung an eine Beschreibung eines Algorithmus den Weg zu einer guten Lösung erschwert oder sogar verbaut. Aus ähnlichen Gründen blieb mir viele Jahre der Zugang zu einer korrekten Double-Array-Trie Implementierung versperrt. Auch dort bedurfte es erst einen neuen Zugang zum Thema um die Blockade zu beenden.

Der Rete Algorithmus (2)

Nachdem im ersten Beitrag zum Rete Algorithmus die grundlegende Arbeitsweise beleuchtet wurde, geht es in diesem Beitrag um die Implementierung. Nicht um einen vollständigen OPS 5 Interpreter, sondern um die Bausteine, aus denen ein funktionsfähiges Rete Netz erstellt werden kann.