Stefan Zörner
24.04.2018
Micro Moves Intro. Einstieg in die Blogserie, Überblick über die Fachlichkeit.
Vertikale Architekturstile wie Microservices und Self-contained Systems sind in aller Munde. Beispiele für deren Umsetzung mit einer konkreten Technologie, etwa Spring Boot, finden sich reichlich im Netz. Bestimmte Aspekte kommen in der Diskussion meiner Meinung nach allerdings zu kurz — vor allem konzeptionelle. Hierzu zählen etwa die UI-Integration zwischen unterschiedlichen Services und Security-Themen — und ganz generell die Frage nach Makro- und Mikroarchitektur. Was ist für alle Services gleich? Wo profitiert Ihr von speziellen Lösungen? Wie fühlen sich unterschiedliche Technologien an, auch vielleicht im Vergleich zu Sachen die Ihr kennt?
In den nächsten Wochen entsteht hier daher FLEXess (für FLEXible chESS Platform), eine technologisch bunte Online-Schach-Plattform. Zug um Zug zum direkt Nachvollziehen (und Nachbauen). Mit Vertikalen realisiert in unterschiedlichen Programmiersprachen (Java, Python, JavaScript, …). Und querschnittlichen Aspekten wie UIs (von Web-Front mit SPA bis zur nativen App). Sowie der Gelegenheit als menschlicher Spieler gegen den aktuellen Ranglistenersten im Computer-Schach anzutreten.
Am Beispiel entlang diskutiere ich in dieser Serie wichtige Fragestellungen rund um Technologien und Vorgehen. Ich beantworte sie konkret für unsere Applikation und implementiere sie exemplarisch (Quelltexte auf GitHub). Weiter zeigt die Serie Alternativen auf und skizziert mögliche nächste Schritte. Darüber hinaus verweist jede Folge auf weiterführende Literatur und aus unserer Sicht qualitativ hochwertige Quellen im Netz.
Ihr wollt unterschiedlichste Technologien in einer überschaubaren aber gleichzeitig attraktiven Applikation gemeinsam am Werkeln sehen? Ihr wollt Eurer Wissen zu modernen Architekturstilen und Microservices Patterns auf- oder ausbauen? Und Orientierung in typischen Architekturentscheidungen erhalten.
Na dann los!
FLEXess erlaubt es den Benutzern gegeneinander Schach zu spielen, oder sich mit Computer-Gegnern zu messen. Fachlich zerfällt das ganze in Themen, die wir in unterschiedlichen Teilsystemen implementieren. Für die fachliche Zerlegung größerer Systeme etabliert sich in der Praxis der strategische Teil von Domain-driven Design (DDD). Zentraler Zerlegungsbegriff sind (Sub-)domänen. DDD kategorisiert diese in Core Domains, Supporting Domains und Generic Subdomains und etabliert Muster der Zusammenarbeit für Teams, welche diese Teile umsetzen.
Ich möchte dem Thema hier gar nicht viel Raum geben – eine grobe Context Map zur Visualisierung der Fachlichkeit soll genügen:
| Subdomäne | Begriffe (Auswahl) | Aufgabe / Verantwortlichkeit |
| Laufende Partien | Gegner, Partie, Zug | Einleiten und verwalten laufender Partien |
| Spieler | Spieler | Verwaltung der (menschlichen) Spieler, Registrierung etc. |
| Spielregeln | Position, Züge | Überprüfen von Zügen auf Gültigkeit, Test auf Partie-Ende ... |
| Diagramme | Bild | Generierung von Schachdiagrammen als Graphiken (z.B. als PNG) zur Einbindung in Webseiten, Berichte etc. |
| Computer-Gegner | Chess Engine | Anbindung von Computerschachprogrammen |
Statt der Standardliteratur zu DDD möchte ich Interessierten die schöne Materialsammlung von Nick Tune zum Thema Strategisches DDD ans Herz legen! In dem klasse gestalteten E-Book beschreibt der Autor Techniken wie Business Canvas, Event Storming etc.
In unserer Blogserie soll der Schwerpunkt jedoch auf der Umsetzung liegen.
Eine allgemein akzeptierte Definition für Microservices gibt es nicht. Und schlußendlich ist es auch egal, ob unsere Umsetzung einen Architekturstil “gültig” implementiert. Gerade bei Microservices gibt es viel Gestaltungs- und Entscheidungsspielraum.
Martin Fowler und James Lewis beschreiben in Ihrem viel beachteten Blogbeitrag, der gerne als Definitionsersatz für Microservices mißbraucht wird, von einem Ansatz, der eine einzelne Anwendung mit Hilfe kleiner Services umsetzt. Diese laufen in eigenen Prozessen und kommunizieren über leichtgewichtige Mechanismen.
Die folgende Abbildung gibt einen groben Überblick über die Umsetzung von FLEXess, wie sie in den folgenden Wochen hier entstehen soll. Änderungen nicht ausgeschlossen, sondern umgekehrt wahrscheinlich.
Die folgende Tabelle ordnet die vertikalen Services den fachlichen Subdomänen aus der Context Map oben zu und nennt die wesentlichen verbauten Technologien und den Blogbeitrag, in dem sie erstmalig eingeführt werden …
| Service | Subdomäne | Wesentliche Technologien | Blog-Beitrag |
| chess-diagrams | Diagramme | Python, Flask, Pillow | Folge 2 |
| games | Laufende Partien | Java, Spring Boot | Folge 1 |
| rules | Spielregeln | ||
| players | Spieler |
FLEXess unterstützt Web-Browser als UIs, weiterhin bietet es eine native Android-App für einen Teil seiner Funktionalität an (das Spielen von Partien). Als Kommunikation kommen im Wesentlichen HTTP und REST zum Einsatz, asynchrone Kommunikation über Messaging. Ein Reverse Proxy lässt die darunter liegenden Vertikalen (Services), die als eigenständige Prozesse laufen, wie eine Anwendung erscheinen.
Aber der Reihe nach.
Wir beginnen in den nächsten Folgen mit der Umsetzung der ersten zwei Services. Anschließend diskutieren wir die UI-Frage – klassische Web-Applikation vs. SPA (Single Page Applikation) etc. – und stellen die zwei Vertikalen in einem Browser zur Verfügung. Den Anfang macht aber das Partien-Subsystem “games” mit einer rein REST-basierten Schnittstelle …
Ach ja: Fragen und Anregungen sind natürlich jederzeit gerne Willkommen. Per Kommentar direkt hier oder gerne auch per Mail direkt an mich.