Gedanken zur agilen Softwareentwicklung
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.
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.
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.
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.
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.
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.
Als Software Entwickler lernt man immer wieder neue Varianten eindeutiger Kennzeichner kennen. Da gibt es die bekannten Kennzeichner wie die Telefonnummern, Kreditkartennummern, PLZ, ISBN, EAN-13, IATA, IBAN, BIC, die veraltete BLZ und nicht so bekannte wie die internationalen Patentnummern, Kreisgemeindeschlüssel und die Leitweg ID. Alle diese Kennzeichner müssen erkannt, geprüft, interpretiert und geschrieben werden können.
Wer ein Attribut in seiner Entity speichern möchte, das ein Set von Enum Werten enthält, kann dies in JPA sehr einfach realisieren. Manchmal fragen einen die Kollegen dann aber doch, ob es nicht andere Wege gibt, ohne eine zusätzliche Tabelle zu verwenden.
Wer seine Daten in der Persistenzschicht ablegen möchte, hat häufig mit relationalen Datenbanken zu tun. Obwohl Frameworks wie Hibernate und JPA das Hantieren mit lästigen SQL Aufrufen häufig vergessen lassen, muss man hin und wieder schauen, was im Hintergrund geschieht.
In den ersten und zweiten Beitrag dieser Reihe wurde ein Annotation Processor implementiert, der bei der Feststellung von Unterschieden zwischen zwei Java Beans unterstützt. In diesem Beitrag soll die Implementierung für Collection Klassen und Bean Strukturen erweitert werden.