Eine Woche Neos Code-Sprint

Vom 18. bis 22.9. haben wir einen Code-Sprint für das Neos Projekt bei uns in der Agentur veranstaltet. Im Rahmen der digitalen Woche Kiel haben wir die Chance genutzt und langjährige Mitglieder des Neos Teams sowie Gäste zu uns eingeladen, um eine Woche an einem speziellen Thema zu arbeiten: der Umstellung des sogenannten Content-Repositories auf eine Event-Sourced Architektur.

Das hört sich erst einmal kompliziert an und bei einigen Diskussionen sind wir auch sehr tief in die Materie abgestiegen, um grundlegende Konzepte in Neos weiter zu definieren und zu durchdenken. Für die technischen Details hat Sebastian Kurfürst einen sehr umfangreichen Blog-Eintrag zum Event Sourced Content Repository erstellt. Aber was bedeutet das eigentlich für Anwender von Neos (Redakteure, Integratoren und Entwickler)?

Der Kern von Neos: das Content Repository

Das Content-Repository in Neos kann man sich wie eine auf Inhalte spezialisierte Datenbank vorstellen. Inhalte sind dabei sehr generell zu verstehen und gehen weit über Bilder oder Texte hinaus. Definierte Inhaltstypen (Node-Types) legen genau fest, welche Felder es gibt, wie sie bearbeitet werden können und was ein Inhaltselement für Beschränkungen hat. Das ist eine der größten Stärken von Neos, die für eine vergleichbar kurze Entwicklungszeit auch komplexerer Strukturen sorgt (z.B. für Produktdarstellung, strukturierte Daten aber auch flexible und interessante responsive Layouts).

Allen Inhalten gemein ist, dass das Content-Repository sich um eine Verwaltung in sogenannten Workspaces kümmert. D.h. Änderungen sind nicht sofort sichtbar, sondern können kontrolliert in einem Rutsch veröffentlicht werden. Dies kann auch in einer Hierarchie erfolgen, so dass z.B. ein gemeinsamer Workspace für eine Kampagne oder ein Team erstellt werden kann.

Eine weitere wichtige Funktion nach der ersten Veröffentlichung von Neos waren die sogenannten Content-Dimensions. Diese ermöglichen eine flexible Abbildung z.B. von Übersetzungen nach Sprachen, aber auch in Kombination mit anderen Merkmalen (den Dimensionen) wie z.B. Land oder Zielgruppe. Die Merkmale und deren Beziehungen (z.B. "Nimm deutschen Inhalt, falls keine österreichische Übersetzung existiert") können frei definiert werden: Neos gibt keine feste Struktur für Sprachen und andere Merkmale vor.

Mit der Zeit sorgte die Kombination dieser Funktionen für den einen oder anderen Fehler der im Rahmen der Versorgung mit Updates bis zur Version 2.3 LTS von Neos behoben wurde. Dies erfordert natürlich einen steigenden Aufwand im Neos Team und auch dort ist längst nicht jeder ein Experte im Bereich des Content-Repositories.

Zudem wollen wir gerne weitere Funktionen wie Undo, Versionierung, Synchronisation von Inhalten über Instanzen und viele weitere Ideen verwirklichen, die Neos noch interessanter für einige Projekte machen würden.

Komplexität beherrschbar machen

Am Ende geht es neben technischen Details vor allem um eins: eine Software zu entwickeln, die im Kern verständlich ist und zusammen im Neos Team und weiteren Mitwirkenden weiterentwickelt werden kann.

Mit dem ursprünglichen Ansatz bei dem zwar möglichst auf eine gute Struktur in einem Domain-Driven-Design Ansatz geachtet wurde und auch eine Abstraktion gegenüber dem Anwender gegeben ist, können die Ziele nicht weiter erreicht werden. Gerade der Einsatz eines sehr aktiven Modells (jede Aktion hat gleich eine Auswirkung) und dem Einsatz eines sogenannten Objekt-Relationen-Mappers (ORM) für ein verbundenes Objektmodell sorgte für eine immer weiter steigende Komplexität. Zudem wurden einige Erweiterungen eher als Nachgedanke in das Modell integriert, so dass auch die Benennungen und Konzepte einer Überholung bedurften.

Seit einiger Zeit schon ist das Thema Event-Sourcing Teil des Neos und Flow Universums, und viele Entwickler aus dem Team aber auch dem Umfeld haben sich mit den Konzepten vertraut gemacht und setzen diese bereits produktiv in durchaus größeren Anwendungen ein. Auch ich war bei einem Workshop im letzen Jahr in Frankfurt mit Mathias Verraes, einem Experten in diesem Bereich, dabei um die Anwendung auf das spezifische Problem des Content-Repositories zu besprechen.

Ein wichtiges Prinzip ist eine Art Umkehr der Denkweise: anstatt in den resultierenden Datenstrukturen zu denken, machen Events die eigentlichen Daten einer Anwendung aus. Im Hintergrund werden dann unterschiedliche Repräsentationen (sogenannte Projektionen) aufgebaut. Ein Event ist dabei wie eine strukturierte Nachricht zu sehen, die an einem bestimmten Zeitpunkt erfolgt ist und in einer Reihe abgelegt wird. Eine Event-Sourced Architektur baut dabei auf den Events als "einzige Wahrheit" des Systems auf und spielt diese in gewissen Fälle auch wieder komplett ab, um den Ist-Zustand zu erhalten. Ein großer Vorteil ist, das für eine Modellierung eines Systems nicht mehr wilde Zeichnungen mit vielen Strichen entstehen, sondern Post-its mit den sprechenden Namen der Events schon einen guten Überblick geben können. Das ganze ist auch im Prinzip des Event-Stormings verankert, einem interessanten Ansatz auch für Kunden-Workshops zur Analyse von Anforderungen.

Und neu ist das Prinzip in dieser Form auch nicht: das Bankwesen und viele andere Bereiche setzen genau auf dieser Art der Abbildung von Daten auf.

Das Prinzip Event-Sourcing wird heutzutage häufig mit dem Prinzip CQRS kombiniert. Ein recht schwer zu behaltenes Akronym mit der Bedeutung "Command Query Responsibility Segregation". Am Ende kann man dazu vereinfacht sagen: die schreibende und lesende Seite eines Systems wird getrennt anstatt in einer Struktur beides abzubilden. Dadurch kann vor allem die lesende Seite, die in einem System wie Neos einen Großteil der Anfragen ausmacht besonders optimiert werden, indem dort andere Strukturen verwendet werden.

Der Anfang ist gemacht

Im Rahmen des Sprints haben wir also gemeinsam auf dem Workshop aufbauend an einer konkreten Umsetzung für ein Event-Sourced Content-Repository in einer CQRS Architektur gearbeitet. Wie es so häufig ist, hat sich dann gezeigt, dass die theoretisch erarbeiteten Konzepte zwar sehr hilfreich aber noch nicht ausreichend für eine tatsächliche Umsetzung waren. So sind dann auch die ersten 3 Tage mindestens zur Hälfte mit Diskussionen gefüllt worden. Vor allem die sprachliche Verfeinerung und eine exakte Definition für Inhalte, zusammenhängende Inhalte in verschiedenen Ausprägungen sowie die Begrifflichkeit zur Definition der Dimensionen wurden erarbeitet und direkt im Prototyp umgesetzt. Auch die Abläufe in Workspaces haben wir exakter definiert und viel Zeit darauf verwendet ein Verfahren zu finden, bei dem mehr Kontrolle über die publizierten Änderungen und eine vollständige Isolation bei der Arbeit in verschiedenen Workspaces gegeben ist (dazu sehen wir eine automatische Aktualisierung von Inhalten im Workspace mit in der Zwischenzeit bereits veröffentlichten Änderungen vor - dadurch sind aber auch neue Features möglich bei denen dies nicht der Fall ist). Ein Ziel dabei ist auch, dass ein Redakteur einfacher die Änderungen in einem Workspace prüfen und freigeben kann oder auf Konflikte und deren Optionen zur Behebung hingewiesen werden kann.

Eine wichtige Anforderung für uns ist, dass die Abwärtskompatibilität zu bisherigen Anwendungen, die für das Content-Repository entwickelt wurden, gegeben sein muss. Dazu gehört nicht zuletzt Neos, aber auch viele Pakete die selber auf das Content-Repository zugreifen (über eine sogenannte API) um Inhalte zu lesen oder zu schreiben (z.B. für einen Produktimport aus einem ERP).

Zum Glück wurde bei der Entwicklung schon an vielen Stellen die Abstraktion vorgesehen, so dass wir eine neue Implementierung "unter der Haube" vornehmen können, ohne dass jede Entwicklung komplett angepasst werden muss. Im aktuellen Stand können Inhalte angelegt, verschoben und Eigenschaften zugewiesen werden. Auch Dimensionen werden nach der neuen Definition korrekt abgebildet. Die Arbeit mit hierarchischen Workspaces wird auch bereits abgebildet, die Veröffentlichung und Aktualisierung ist jedoch noch als Prototyp aufzubauen.

Wir sind sehr gespannt wie schnell wir mit den weiteren Arbeiten nach dem Sprint vorwärts kommen und planen ein regelmäßiges Treffen als Videokonferenz mit allen Beteiligten und Interessierten einzuführen, damit wir uns weiter abstimmen und Teilaufgaben verteilen können. Das Neos React UI hat dies bereits mit großem Erfolg vorgemacht und über längere Zeit die Entwicklung bis zur Produktionsreife weitergeführt.

Einen genauen Termin für die Fertigstellung und allgemeine Verfügbarkeit in Neos können wir bis jetzt noch nicht festlegen, dazu ist das Projekt noch nicht weit genug fortgeschritten. Es scheint jedoch nicht unmöglich zu sein, die neue Implementierung bis zur nächsten Major-Version fertigzustellen.