Posts mit dem Label Programmierung werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Programmierung werden angezeigt. Alle Posts anzeigen

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

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)

Dienstag, 10. Juni 2014

Open Source REST Server-Anwendung (Dropwizard - Google Guice - JPA Hibernate)

Vor ziemlich genau einem Jahr habe ich mich dazu entschieden, das Java-Webframework Dropwizard für unsere Server-Anwendung einzusetzen. Seitdem habe ich viel gelesen, viel gelernt und auch Einiges in unserer Server-Anwendung implementiert. Nun stand eine Umstellung auf die neueste Dropwizard-Version an. Diese Gelegenheit habe ich dafür genutzt, Alles nochmal "von vorne" zu entwickeln, um meine Erkenntnisse über die Anwendung zu festigen. Ich möchte die komplette Implementierung dauerhaft überblicken, verstehen und gescheit dokumentieren. Das wird anderen dabei helfen, in die Entwicklung mit einzusteigen und den Code langfristig wartbar zu halten.

Um die ganzen technischen Features der Server-Anwendung für die Allgemeinheit zur Verfügung zu stellen, habe ich eine neue Anwendung erstellt, die alleinstehend und außerhalb des Oregami-Kontextes lauffähig und sinnvoll ist und eine klassische "ToDo-Applikation" darstellt. Ihr wisst schon: eine Liste von Dingen (Name, Beschreibung, Status, ...), die man noch erledigen muss.

Die Anwendung enthält momentan die folgenden technischen Features:
  • REST-Anwendung basierend auf Dropwizard Version 0.7.0
  • Dependency Injection mit Google Guice
  • Hibernate / JPA 2.1 als Persistenz-Framework
  • HSQLDB als (In-Memory-)Datenbank
  • "Transaction-per-HTTP-request" mit Guice PersistentFilter
  • Unterstützung für cross-origin resource sharing
  • JPA Entitäten mit UUIDs als Identifikator
  • Ein Muster für den Zugriff und die Manipulation von Entitäten über REST Aufrufe
    (Ressource => Service => DataAccessObject)
  • Ein Muster für Service-Aufruf-Ergebnisse, welche Fehlermeldungen enthalten können, inkl. der Information, bei welchem Feld der Anwendung der Fehler aufgetreten ist. Auf diese Weise kann später in der Weboberfläche die Fehlermeldung an der richtigen Stelle eingeblendet werden.
  • Durchgehende JUnit-Tests zur Absicherung der korrekten Funktionalität
In möglichst naher Zukunft sollen die folgende Dinge noch hinzugefügt werden:
  • Authentifizierung
  • Hypermedia mit HATEOAS
  • komplexere Entitäten (1-zu-n-Beziehungen)

Der Sourcecode steht bei Github unter dem Namen dropwizard-guice-jpa-seed für jedermann zur Verfügung.

Disclaimer: Es kann natürlich sein, dass ihr Dinge findet, die man besser machen kann. In diesem Fall helft gerne mit, die Anwendung zu verbessern! Geht bei Github über die üblichen Pull-Requests. Das gilt natürlich auch für neue, noch fehlende Features!

Hinweise für Enwtickler

Die Anwendung kann gestartet werden über die Klasse "ToDoApplication" mit den Parametern "server todo.yml".

Auflisten der aktuell gespeicherten Tasks über:
GET => http://localhost:8080/task


Hinzufügen eines neuen Tasks über:
POST => http://localhost:8080/task

Header:
Content-Type:application/json
JSON-Body z.B. :
{"name" : "task 1", "description" : "This is a description"}


Modifizieren eines Tasks über:
PUT => http://localhost:8080/task/[id]
Header:
Content-Type:application/json
Accept:application/json

JSON-Body z.B.:
{
    "id": "402880944687600101468760d9ea0000",
    "version": "0",
    "name": "task 1 with new name",
    "description": "This is an updated description",
    "finished": "false"
}


Ich empfehle die Chrome-Erweiterung Postman, um solche HTTP-Aufrufe durchzuführen!

Mittwoch, 8. August 2012

Flotter Dreier mit Jenkins, Git und Tomcat

Das Ziel war klar: Unser Java-Programmcode soll von unserem Jenkins-Build-Server regelmäßig kompiliert und dann auf unseren Tomcat-Server deployt werden. So weit, so gut. Doch dafür mussten einige Hindernisse überwunden werden.

In Bezug auf Versionierungs-Systeme hatte ich in meiner Programmierer-Vergangenheit bislang hauptsächlich Kontakt mit CVS und Subversion. Beide sind heute nicht mehr zeitgemäß, also wird unser Programmcode mit Git verwaltet. Als Hoster habe ich Github ausgewählt, so viele bekannte Projekte können da nicht falsch liegen.

Zudem bin ich es beruflich mittlerweile gewohnt, dass der Programmcode mindestens einmal am Tag "gebaut" wird, der Griff zum Jenkins-Buildserver lag da sehr nah. Und der Tomcat-Server für unsere Java-Webanwendung sollte da leicht angebunden werden können - dachte ich zumindest.