You finally have a Domain Model that represents the business and supports the functionality of the system. Then the hard part: how do you persist that model to a database? Maybe you're a purist (like me), mapping domain objects to separate database entities. or you directly annotate your domain objects, but have to compromise the domain model to fit the way databases store information. Event sourcing avoids this problem while providing flexible transactional (consistency) boundaries. Instead of mapping object state to tables, you store a sequence of events that led up to the current state: "Concert Scheduled", "Tickets Purchased", etc. Each event is added to an append-only log, making writes almost trivial, with "projections" making custom-fit views straightforward. However, event sourcing requires a mind-shift from the well-known CRUD and DDD Tactical Patterns (Aggregates and Repositories), but the benefits are more flexible systems, with a less "leaky" way to externalize the state of your domain model that is easier to apply across the domain. In this talk, you'll learn how event-sourcing works at the code level without event-sourcing libraries getting in the way of deeper understanding. We'll walk through a codebase for a Concert Ticketing system and see how straightforward the implementation can be. We start with "Event Modeling" the system, defining the commands (user actions) that generate them, the aggregates that make business decisions (and how to move to "deciders"), and the projections used to generate the user interface. We'll see how event-sourcing makes testing easier to write and understand. We'll end by touching on the challenges to using event-sourcing, such as performance and schema evolution.

Since single page applications have become the de facto standard for building modern web applications, the complexity of frameworks and tools has continued to grow. But does it always have to be an SPA? For many applications, this associated complexity is not necessary. The necessary interactivity of many business applications is minimal. What if HTML were more powerful and, for example, every element could trigger an AJAX request and a response would not always replace the entire page? This presentation looks at central elements of hypermedia applications and how HTMX can implement typical patterns of modern web applications. In combination with modern template engines (Thymeleaf, JTE, JStachio), ‘full-stack development’ is once again possible and even fun!

„Wenn jemand eine Reise tut, so kann er (oder sie) was erzählen. Drum nähme ich den Stock und Hut und tät das Reisen wählen.” (Matthias Claudius, 1740-1815) Der vorliegende Vortrag wurde mit genau diesem, bereits 1000-mal gehörten (und leicht aktualisierten) Sprichwort im Hinterkopf konzipiert. Im Verlauf der vergangenen zehn Jahre entstand so ein Reisebericht, der die Erkenntnisse aus 20+ Jahren im Umfeld der professionellen Softwareentwicklung zusammenfasst und dabei im Kern eine zentrale Frage beleuchtet: „Was hat der Vortragende auf seiner Reise durch die 'freie Wildbahn' als relevant für ein produktives und gedeihliches (Über-)Leben identifiziert?“. Etappen der dokumentierten Reise sind: 1.) Die Charakteristiken von Softwareentwicklung (aka „das komplexe Umfeld“)
 2.) Was ist Erfahrung und wie gelange ich an diese? (aka „das Dreyfus-Lernmodell“)
 3.) Kognitive Verzerrungen und Einflussfaktoren beim Entwickeln von Software
 4.) Der Kern: „Präzision, arbeitsames Raten, unzuverlässige Daten und fragwürdiges Wissen“
 5.) Beobachtungen zu Menschen die programmieren, „Hype Driven Development“ und eine Betrachtung des aktuellen Hype-Themas „KI“
 6.) (Fast) Ewige und aktuelle Herausforderungen (im Kleinen, wie im Großen)
 7.) Technologie & Tools Haben Sie sich demnach auch schon einmal gefragt, warum wir, als Community von hoch bezahlten Experten, so häufig kämpfen, um das Biest namens Softwareentwicklung zu zähmen? Der „Thoughts on (Modern?) Software Development“-Talk liefert einige der möglichen Antworten auf die Frage, warum unser Kampf ein sehr herausfordernder ist - und warum das vermutlich auch so bleiben wird. Spoiler: Die Gründe sind oftmals nicht die, die ein Stakeholder oder auch ein unmittelbar Beteiligter zunächst einmal erwarten würde…