Samstag, 26. November 2016

Domain Driven Design, CQRS, Event Sourcing, Hexagonale Architektur & mehr

Der Weg zur richtigen Software-Architektur kann manchmal lang sein. Oder sogar sehr lang. Insbesondere, wenn man nicht gerade hauptberuflich Software-Architekt ist und dabei quasi jeden Tag bei seinen Kunden die Entwicklung komplexer Software betreibt.

Wie kann Oregami nun den Weg zu einer guten Software-Architektur finden? Wer unser Projekt von Beginn an beobachtet hat, der weiß, dass wir schon mehrmals die bis dato ausgewählte Technik "über den Haufen geworfen" haben. Anfangs hatte ich eine klassische Schichtenarchitektur im Sinn und machte mir hauptsächlich Gedanken darüber, mit welchem Java-Framework wir unsere fachlichen Objekte speichern könnten und welche Datenbank-Software wir einsetzen würden. Bis zum heutigen Tag hat sich in meinem Kopf allerdings viel getan.

Samstag, 9. Juli 2016

Spieledatenbanken-News 01/2016

Auch im Jahr 2016 wollen wir unsere kleine Serie von Blogeinträgen über neue Entwicklungen im Markt für Videospieldatenbanken fortsetzen.

Die Top-Neuigkeiten kamen dieses Mal wieder von der IGDB. Das Kernteam hinter dem Projekt hat nämlich offensichtlich Investoren gefunden, die an den zukünftigen Erfolg der Seite glauben, und kann deshalb nun Vollzeit daran arbeiten. Außerdem wurden eine Reihe von "Insight"-Videos veröffentlicht, in deren erster Episode man sich zum Beispiel IGDBs Hauptquartier und das Kernteam anschauen kann. Außerdem hat der leitende Entwickler des Projekts ein 46-minütiges Video veröffentlicht, in dem er, ein Novum in der Geschichte der Spieledatenbanken, detailliert auf die technischen Hintergründe der IGDB eingeht.

Ein Schritt zurück - zwei Schritte nach vorne?


Wer das Projekt Oregami beobachtet, der wird bemerkt haben, dass es seit ein paar Monaten etwas ruhiger geworden ist in der Oregami-Welt. Der Grund dafür? Das restliche Leben! (smile) Aber genau dafür entwickeln wir ja Alles offen: Datenmodell, Ideensammlung, Programmcode. Nichts geht verloren, jedermann kann jederzeit mit aufspringen auf den Zug der ersten komplett offenen Spieledatenbank!
Der Anlass für diesen Blogbeitrag ist meine schon länger vorhandene Aufmerksamkeit gegenüber dem Projekt Spring Boot. Spring Boot unterstützt die Entwicklung eigenständig lauffähiger Spring-Anwendungen per Konvention vor Konfiguration, die ohne XML-Konfiguration auskommen und alle nötigen Klassenbibliotheken mitbringen. Als ich vor ca. zwei Jahren die Oregami-Entwicklung (der REST-Server-Anwendung) auf Dropwizard umstellte, stand Dropwizard mit seinen Fähigkeiten noch ziemlich alleine da. Ein Java-Framework, dass seinen Server "eingebettet" mitbringt und so die Entwicklung von Webanwendungen erheblich vereinfacht: genau das suchte ich. Nie wieder einen sperrigen Application Server "deployen" oder "publishen".
Mittlerweile ist Spring Boot auf der Spielfläche erschienen. Im April 2014 erschien V 1.0, heute ist Version 1.3 die aktuellste Fassung. Was wäre nun, wenn ich versuchen würde, den bisherigen Stand neu mit Spring Boot zu realisieren? Dazu möchte ich aber erstmal aufführen, was wir bislang alles "lauffähig" haben:
  • REST-Anwendung mit Fachobjekten wie "Game", "PublicationFranchise", "GamingEnvironment" und mehr
  • HTTP-Anfragen für GET (Lesen), POST (Anlegen) und PUT (Ändern) von Fachobjekten
  • Anlegen und Editieren von Fachobjekten über den Browser
  • Authentifizierung mit JSON Web Tokens
  • "Session-per-HTTP-request": eine Datenbank-Transaktion pro HTTP-Request
  • HSQLDB für die Entwicklung, MySQL für den "deployten" Stand
  • JPA entities mit UUIDs als Primary Key
  • Liquibase für einfache Datenbank-Schema-Updates
  • Versionierung von Fachobjekten mit Hibernate Envers
  • Integrationstests mit rest-assured
Diese Dinge müssten natürlich so oder in ähnlicher Form auch in einer Neu-Implementierung mit Spring Boot vorhanden sein.
Aber es stellt sich außerdem noch die Frage: Bleiben wir bei der bisher gewählten Anwendungsarchitektur REST-Server + JavaScript Single Page Application?
In meinem Kopf spielt sich seit einigen Jahren ein Kampf der Architekturen ab. Eine REST-Schnittstelle nach außen ist für mich ein Muss, also entwickelten wir bisher die Oregami-Spieledatenbank als REST-Anwendung mit einem Web-Client in Form einer "Single Page Application". Das ist in gewisser Weise elegant und macht bei der Entwicklung Spaß. Aber ist es wirklich die beste Lösung? Das fragen sich auch Andere:
Vor einigen Monaten habe ich mir das Buch "Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement (2nd Edition)" von Aaron Gustafson zugelegt. Die Idee, eine Webseite im ersten Schritt mit Standard-Technologien nutzbar zu machen, sie danach schrittweise zu verbessern und dadurch dafür zu sorgen, dass die Webseite mit jeglicher Web-Software auf jeden Fall benutzbar ist, gefällt mir immer besser. Mit diesen Gedanken im Hinterkopf habe ich vor einigen Monaten damit begonnen, meine (andere) Webseite Kultpower.de komplett neu zu entwickeln. Neben dem "Progressive Enhancement" verfolgte ich auch gleich den Ansatz "Mobile First": Die Webseite wird erstmal für kleine Bildschirme (z.B. Smartphones) entwickelt, anschließend werden - in der gleichen Code-Basis - Verbesserungen für größere Bildschirme eingebaut. Das bisherige Ergebnis ist zu finden unter www.Kultpower.org (unbedingt auch mal mit dem Smartphone ausprobieren), ich bin damit sehr zufrieden!
Unter dem Synonym "Roca-Style" (Resource Oriented Client Architecture) wird eine Sammlung von Empfehlungen beschrieben, die man bei der Entwicklung von Webseiten berücksichtigen kann. Nach diesen Empfehlungen möchte ich den bisherigen Stand der Oregami-Spieledatenbank neu entwickeln. Ich werde viel Programmcode (das Fachliche bezüglich Games, Publications usw.) wiederverwenden können und meine Erfahrungen aus dem Kultpower.org-Projekt einfließen lassen. Unser bisheriger JavaScript-Client wird dann abgelöst werden durch serverseitiges Rendern der Seiten mit der Template-Engine Thymeleaf.
Es gilt also wie immer bei Oregami: stay tuned! (big grin)