JAX 2019 - Frühjahr

Monolithen vs. Micro-Services

Es spricht generell nichts gegen einen gut strukturierten Monolithen und Micro-Services sind kein Allheilmittel! Wenn man einen „Big Ball of Mud“ (Wollknäuel, Monolithisches Konstrukt mit hohen Abhängigkeiten zwischen den Modulen) in Micro-Services aufteilt, bekommt man typischerweise einen „Distributed Big Ball of Mud“. Dies ist die schlechteste Lösung, da man alle Nachteile des Monolithen mit den Nachteilen von Micro-Services kombiniert.

Domain-Driven Design

Das Modell soll die Wirklichkeit abbilden, sprich der Code soll nicht mehr ermöglichen als die Realität. Ein schlechtes Zeichen sind beispielsweise Setter für jedes Feld. „Setters cause model anemia“ („Blutleere“ Domänenmodelle). Man soll unbedingt die „Ubiquitous language“, also die Worte der Fachlichkeit nutzen. Wenn also die Fachsprache Deutsch ist, soll man diese auch verwenden.

Wichtig bei DDD: Duplications im Domänenmodell sind ausdrücklich erwünscht. Wenn mehrere Sub-Domains die „gleiche“ Entity benötigt, implementiert jede Sub-Domain die eigene Sicht darauf. „Sharing“ einer Entity führt zu Abhängigkeiten zwischen den „Bounded Contexts“ (abgegrenzte Bereiche innerhalb der Domäne) und ist daher unerwünscht.
DDD war auch Thema von Ludwigs Workshops am Montag. Anhand eines praktischen Beispiels wurden die „Bounded Contexts“ des Domänenmodell ermittelt und mittels „Event Storming“ eine „Context Map“ erstellt. In dieser wurden die „Domain Events“ und „Trouble Spots“ ausgemacht. Abschließend wurden die Sub Domains in „Core-“, „Supporting-“ und „Generic-Domains“ eingestuft.

Security

Am Montag hat Sabrina beim Pentesting Workshop teilgenommen. Dabei wurde das Bewusstsein für die kritischsten Sicherheitslücken geschaffen, und gezeigt wie wir diese finden und verhindern können. Der praktische Teil war sehr interessant, weil wir eine unsichere Webapplikation angreifen durften und selbstständig versucht haben, verschiedenste Arten von Sicherheitslücken zu finden, zB SQL Injection oder Cross-Site Scripting.
Erkenntnisse aus dem Vortrag “Die sieben Security-Sünden agiler Projekte” sind, dass es für eine sichere Applikation wichtig ist sich zu überlegen, wo die Applikation angreifbar ist (Whiteboard Hacking). Automatisierte Security-Tests und Aktualisieren von Dependencies sollte ebenfalls gemacht werden. Jährliche Pentests und Vorbereitung auf einen potentiellen Angriff, zB durch hilfreiches Logging und Monitoring, ist empfehlenswert.

Hibernate Workshop jenseits von CRUD

Am Freitag haben wir beide an einem Power-Workshop zu Hibernate teilgenommen. Nach jeweils einer kurzen theoretischen Einführung wurde das gelernte gleich anhand mehrerer Programmier-Übungen praktisch umgesetzt. Die Themen waren „Multitenancy“ (Trennen der Daten bei Applikation mit mehreren Mandanten), „Volltextsuche mit Lucene bzw. Elasticsearch“ und „Auditing/Versionierung mit Envers Audit“.

Neues (Lizenz-)Modell von Oracle JDK

Updates gibt es alle 3 Monate, Feature Releases alle 6 Monate. Versionen mit LTS kommen alle 3 Jahre (JDK 11, 17, 23, …). Oracle JDK 1.8_201 ist die letzte freie LTS Version.

Wichtig: Oracle JDK ist für Entwickler selbst immer frei, erst sobald die Runtime „kommerziell verwendet wird“ ist eine Subscription notwendig. Wenn beispielsweise ein anderes System die Java Runtime nutzt (z.B. Jenkins) ist das auch während des Entwicklungsprozesses kostenpflichtig.
Parallel zur Oracle JDK gibt es Oracle OpenJDK, wofür keine Subscription benötigt wird. Allerdings sind dafür nur 2 Sicherheitspatches vorgesehen, dann folgt die nächste Version.

Java in Containern

Ziele: Schnellere Startup Times, häufige Deployments, GC mit sehr kurzen Latenzen, weniger Speicher, kleinere Runtimes, „static compile“ statt JIT

Neuerungen in JAVA 9-12

Shenandoah

In diesem Vortrag wurde die Funktionsweise von Shenandoah erläutert. Shenandoah ist ein neuer Garbage Collector (ab JDK12) mit sehr niedrigen Stop-the-world Zeiten (<10 ms). Als Ausgleich dafür ist allerdings das Erzeugen von Objekten, Lese- und Schreibzugriff verlangsamt und der Heap vergrößert.

Neuerungen im SQL-Standard seit SQL-92

Durchgängiger Tenor: SQL ist eine sehr leistungsfähige, transformative Sprache, die von den meisten nur für CRUD genutzt wird obwohl sich viele Aufgaben bzw. Probleme einfacher, effizienter und performanter direkt in SQL lösen lassen würden (Provokantes Stichwort: „Business logic in the persistence layer / database“.
Neue Funktionalitäten sind beispielsweise GROUPING SETS für mehrere GROUP BY-Klauseln, WITH RECURSIVE für Rekursionen oder OVER für Aggregationen ohne Merge der Zeilen.
Viele Features des Standards werden selbst nach 10-20 Jahren noch nicht von den großen DBs unterstützt. Prominentes Beispiel: Seit SQL-2011 gibt es „System Versioning“, mit dem Auditing und Historization automatisch und ohne großes zutun in der Datenbank möglich wäre. Es wird aber wie viele anderen Features noch von keiner DB umgesetzt.

Kubernetes Patterns

Es wurden einige Patterns für Kubernetes vorgestellt, die auch für Openshift anwendbar sind:

Timeless Design Principles over Time

Es wurden die „modular Design Principles“ (single responsibility, polymorphism, interface segregation und encapsulation) anhand von aktuellen Sprachen (Kotlin), ältere Sprachen (Ruby, Visual Basic, C) bis hin zu SIMULA67 (die erste „objekt-orientierte“ Sprache aus den 60er Jahren) betrachtet.

Technical Excellence in agilen Projekten