GrowGoods Greenprint - Unsere technische Reise mit ValueFlows und REA-Accounting

G’day! Haben Sie sich jemals gefragt, was es braucht, um eine Software zu entwickeln, die einen Bauernhof wirklich versteht? Nicht nur die Gewinne und Verluste, sondern auch die Gesundheit des Bodens, den Wert gemeinsamer Arbeit und das komplexe Zusammenspiel eines regenerativen Ökosystems?

Genau das ist die Herausforderung, der wir uns bei GrowGood stellen. Unsere Reise zur Entwicklung einer transparenten, quelloffenen AgTech-Plattform hat uns auf einen faszinierenden technischen Weg geführt, geleitet von den robusten Prinzipien von ValueFlows und der Resource-Event-Agent (REA) Buchhaltung (Accounting).

Also, holen Sie sich eine Tasse Kaffee, denn wir werden uns nun in die Details vertiefen – die reizvollen technischen Details, um genau zu sein – unserer Architektur, der Herausforderungen, denen wir uns gestellt haben, und der Gründe, warum Sie vielleicht mit uns auf die Weide kommen möchten.

Warum ValueFlows und REA? Das Fundament der Wahrheit

Traditionelle Farmmanagement-Software konzentriert sich oft auf isolierte Metriken: Ertrag pro Hektar, Kosten pro Einheit, Gewinnmargen. Obwohl nützlich, greift dieser Ansatz zu kurz, wenn versucht wird, die ganzheitliche, vernetzte Natur regenerativer Praktiken zu erfassen. Wie berücksichtigen Sie erhöhten organischen Kohlenstoff im Boden, verbesserte Biodiversität oder den Wert gemeinsamer Gemeinschaftsarbeit?

Genau dieses Problem löst ValueFlows. Es ist eine formale Ontologie (ein schickes Wort für ein gemeinsames Vokabular) zur Beschreibung wirtschaftlicher Netzwerke. Im Kern steht die REA-Buchhaltung, die alle wirtschaftlichen Aktivitäten als Veränderungen von Ressourcen betrachtet, die durch Ereignisse verursacht werden, an denen Agenten beteiligt sind.

Für uns bedeutet das:

• Ganzheitliche Buchführung: Jeder Input (Samen, Wasser, Aufwand), jeder Output (Karotten, Milch, verbesserte Bodengesundheit) und jede Transformation (Pflanzen, Ernten, Kompostieren) ist ein Economic Event in unserem System. Dies ist nicht nur finanziell; es umfasst auch ökologischen und sozialen Wert.
• Echte Rückverfolgbarkeit: Da jedes Ereignis auf die beteiligten Ressourcen, Agenten und Prozesse zurückverfolgt werden kann, erstellen wir eine unveränderliche, nachprüfbare Prüfspur. Dies ist entscheidend, um Nachhaltigkeitsansprüche zu beweisen – kein Greenwashing hier!
• Interoperabilität: ValueFlows ist ein weithin anerkannter Standard. Durch die Ausrichtung darauf kann GrowGood nahtlos mit anderen VF-konformen Systemen verbunden werden, was verteilte Wirtschaftsnetzwerke ermöglicht (denken Sie an lokale Lebensmittelwirtschaften, Lieferkettentransparenz und sogar Kohlenstoffmärkte).

Es geht nicht nur um bessere Daten; es geht darum, Daten sinnvoll und handhabbar zu machen, auf eine Weise, die die Werte der regenerativen Landwirtschaft wirklich widerspiegelt.

Die Architektur: Ein pythonisches Rückgrat mit einem flatternden Herzen

Unser Backend ist eine schlanke, gemeine FastAPI-Maschine, angetrieben von den asynchronen Fähigkeiten von Python. Wir haben es mit einer robusten PostgreSQL-Datenbank kombiniert, die mit PostGIS für all unsere räumlichen Datenanforderungen aufgeladen ist – denn auf einem Bauernhof ist wo etwas passiert oft genauso wichtig wie was passiert.

Architektonisch sind wir fest im Domain-Driven Design (DDD) und Command Query Responsibility Segregation (CQRS) verwurzelt. Das mag einschüchternd klingen, bedeutet aber im Wesentlichen, dass wir trennen, wie wir Daten ändern (Befehle), von dem, wie wir sie lesen (Abfragen), um sowohl Leistung als auch konzeptionelle Klarheit zu optimieren. Unsere Economic Events sind die einzige Quelle der Wahrheit; der gesamte andere Anwendungszustand wird als Projektionen aus diesem unveränderlichen Ereignisstrom abgeleitet.

An der Frontend-Front haben wir uns nach reiflicher Überlegung (und ein paar ADRs!) für Flutter entschieden. Dies war eine entscheidende Entscheidung, die es uns ermöglicht, eine einzige, schöne Codebasis zu erstellen, die nativ auf Mobilgeräten (entscheidend für den Einsatz im Feld), auf dem Desktop (perfekt für die Admin-Benutzeroberfläche) und sogar im Web läuft.

Die Reise: Vom Text zur interaktiven Leinwand

Unser Weg zu einer visuellen, von ValueFlows gesteuerten Admin-Benutzeroberfläche umfasste mehrere Prototyping-Umwege, von denen jeder uns unschätzbare Lektionen lehrte.

Phase 1: Die DSL – Wirtschaftliche Ströme in Text skizzieren

Unser erster Schritt war die Definition einer ValueFlows Domain Specific Language (vf-dsl). Inspiriert von Tools wie Mermaid.js ist dies eine für Menschen lesbare, textbasierte Syntax zum Skizzieren von Rezepten (unseren VF-Prozessvorlagen).

# Beispiel vf-dsl-Snippet
process "Tomaten pflanzen" {
    input "Tomatensamen" (quantity: 10g)
    output "Tomatensämlinge" (quantity: 50 plants)
    agent "Bäuerin Jane"
}

Diese DSL erwies sich als unglaublich leistungsstark für schnelles Prototyping und Versionskontrolle. Entwickler konnten komplexe Arbeitsabläufe schnell in einfachem Text definieren, was die Überprüfung und Diskussion von Änderungen erleichterte.

Phase 2: Jupyter – Der Spielplatz des Entwicklers

Unser Jupyter-Prototyp (dsl_tester_demo.ipynb) war eine Sandbox für unseren DSL-Parser und -Validator. Hier konnten wir:

• DSL parsen: vf-dsl in ein strukturiertes Python-Wörterbuch umwandeln, das Knoten und Kanten darstellt.
• Beschränkungen validieren: Kernregeln von ValueFlows implementieren, wie z. B. die Überprüfung auf zirkuläre Abhängigkeiten oder die Sicherstellung, dass alle Mengen Einheiten haben.
• Statische Visualisierung: Einfache, nicht interaktive Diagramme erstellen, um die geparste Struktur visuell zu bestätigen.

Diese Umgebung war von unschätzbarem Wert für die schnelle Iteration der DSL-Spezifikation und der zugrunde liegenden Parsing-Logik.

Phase 3: NiceGUI – Die DSL ins Web bringen (für Feedback)

Da wir erkannten, dass rohe DSL für Endbenutzer nicht ideal war, erstellten wir einen webbasierten Prototyp mit NiceGUI (einem Python-UI-Framework). Dies ermöglichte uns:

• Visualisierung mit VueFlow: Integration einer VueFlow-Komponente, um interaktive, knotenbasierte Diagramme direkt im Browser zu rendern.
• Frühes Feedback einholen: Bereitstellung eines installationsfreien, web-zugänglichen Tools für Farmadministratoren zum Testen der Benutzeroberfläche und zum Geben von Feedback zum Arbeitsablauf des visuellen Editors.

Der NiceGUI-Prototyp diente als entscheidende Brücke und zeigte, wie die textbasierte DSL eine reichhaltige grafische Oberfläche untermauern kann. Es bewies, dass ein hybrider Ansatz – die Verwendung von DSL für schnelles Scaffolding und Versionierung und eines visuellen Editors für intuitive Interaktion – das Beste aus beiden Welten bot.

Phase 4: Flutter – Die Erfahrung vereinheitlichen

Unsere jüngste und strategischste Entscheidung war es, sowohl die operativen (mobil-orientierten) als auch die Administrator- (desktop-orientierten) Benutzeroberflächen unter einer einzigen Flutter-Codebasis zu vereinheitlichen. Dies wurde in ADR-010: Use Flutter for Operational and Administrator UIs festgehalten.

Warum Flutter?

• Native Leistung: Entscheidend für eine reibungslose, reaktionsschnelle Erfahrung auf Mobilgeräten (oft in Umgebungen mit geringer Konnektivität) und auf dem Desktop.
• Echte plattformübergreifende Entwicklung: Eine Codebasis, native Apps für iOS, Android, Windows, macOS, Linux und Web. Dies reduziert unseren Wartungsaufwand als Open-Source-Projekt drastisch.
• Offline-First-Fähigkeiten: Das Ökosystem von Flutter (z. B. drift für lokale Datenbanken) eignet sich perfekt für die Erstellung robuster Offline-First-Anwendungen, ein Muss für Landwirte auf dem Feld.
• Reichhaltiges UI-Toolkit: Ermöglicht uns den Bau des komplexen, interaktiven knotenbasierten Editors für Rezepte, den unsere Admin-Benutzeroberfläche erfordert.

Dieser Wechsel stellt eine Lernkurve für unser auf Python fokussiertes Team dar, aber die langfristigen Vorteile in Bezug auf Wartbarkeit, Konsistenz und Benutzererfahrung sind unbestreitbar.

Herausforderungen und Erkenntnisse

Unsere Reise war nicht ohne Hindernisse und Offenbarungen:

• DSL-Design vs. VF-Reinheit: Die Balance zwischen der Notwendigkeit einer prägnanten, für Menschen lesbaren DSL und der strengen ontologischen Reinheit von ValueFlows war eine ständige Verhandlung. Wir entschieden uns für pragmatische Abkürzungen in der DSL, die dann beim Parsen zu vollständigem VF JSON-LD erweitert werden.
• Komplexität visualisieren: Die Darstellung mehrschichtiger ValueFlows-Konzepte (Rezepte, Pläne, Prozesse, Ereignisse) in einem intuitiven visuellen Diagramm erfordert sorgfältiges Design. Wir neigen zu deutlichen visuellen Hinweisen und interaktiver Filterung, um die Informationsüberflutung zu bewältigen.
• Abgeleiteter Zustand in CQRS: Anfangs neigten wir dazu, abgeleiteten Zustand in unseren Datenbankmodellen zu speichern. Feedback aus der ValueFlows-Community und unser Bekenntnis zu CQRS führten uns zu einem strengeren Event-Sourcing-Modell, bei dem der gesamte Zustand wirklich aus dem unveränderlichen Ereignisprotokoll abgeleitet wird. Dies verbessert die Datenintegrität, erhöht aber die Abfragekomplexität, was ausgefeilte Projektionsdienste erforderlich macht.
• Teststrategie: Mit einer ereignisgesteuerten, plattformübergreifenden Architektur wuchs unsere Testmatrix erheblich. Wir haben in umfassende Unit-, Integrations- und End-to-End-Tests sowie dedizierte DSL-Tests in Jupyter investiert, um die Robustheit zu gewährleisten.

Der Weg nach vorne: Offene Fragen und zukünftige Arbeit

Während wir uns einer vollständigen Flutter-Implementierung der Admin-Benutzeroberfläche nähern, liegen mehrere spannende technische Herausforderungen und Möglichkeiten vor uns:

• Erweiterte Diagramminteraktivität: Aufbau eines hochgradig interaktiven Drag-and-Drop-Knoteneditors in Flutter. Wir untersuchen die Kombination von Bibliotheken wie graphview mit benutzerdefinierten CustomPainter-Implementierungen, um das gewünschte Maß an Kontrolle und Leistung zu erreichen.
• DSL-Round-Tripping: Ermöglicht die nahtlose Konvertierung zwischen dem visuellen Diagramm und der textbasierten DSL, sodass Power-User zwischen den Modi wechseln können.
• Echtzeit-Zusammenarbeit: Wie können mehrere Administratoren ohne Konflikte am Rezeptdesign zusammenarbeiten? Dies öffnet Türen zu CRDTs oder operationalen Transformationsalgorithmen.
• Backend-Skalierung: Wenn GrowGood wächst, wird die Optimierung unseres PostgreSQL/PostGIS-Setups und möglicherweise die Untersuchung von Microservices für bestimmte Domänen von entscheidender Bedeutung sein.

Treten Sie dem Paddock bei! Ein Aufruf für Mitwirkende

Hier kommen Sie ins Spiel, lieber Leser. GrowGood ist ein ehrgeiziges Open-Source-Projekt, und wir glauben an die Kraft der Gemeinschaft.

Wenn Sie ein Entwickler (oder sogar ein angehender!) mit einer Leidenschaft für:

• Flutter sind: Helfen Sie uns, eine schöne, leistungsstarke und intuitive plattformübergreifende Benutzeroberfläche zu erstellen.
• Python/FastAPI sind: Tragen Sie zu unserem robusten Backend bei, erweitern Sie unsere ValueFlows-Integration oder optimieren Sie unsere PostGIS-Abfragen.
• AgTech & Regenerative Landwirtschaft sind: Bringen Sie Ihr Fachwissen ein, um Funktionen zu gestalten, die Landwirte wirklich stärken.
• Open Source sind: Treten Sie einer freundlichen, wachsenden Gemeinschaft bei, die sich dem Aufbau öffentlicher Güter für ein besseres Lebensmittelsystem verschrieben hat.

Wir suchen Leute, die uns bei folgenden Aufgaben helfen:

• Flutter-UI-Entwicklung: Von der Implementierung des Knoteneditors bis zum Erstellen responsiver Layouts.
• Backend-Logik: Erweiterung von ValueFlows-Modellen, Optimierung von Projektionsdiensten und Integration neuer Datenquellen.
• Testen: Sicherstellen, dass unsere Plattform über alle Schichten hinweg kugelsicher ist.
• Dokumentation: Helfen Sie uns, GrowGood einem breiteren Publikum zugänglich zu machen.

Besuchen Sie unser GitLab-Repository, schauen Sie sich unsere Issues an, treten Sie unserem Discord bei und lassen Sie uns gemeinsam diese grüne Revolution kultivieren. Die Zukunft der Lebensmittel ist offen, und sie wird gebaut, ein ValueFlow nach dem anderen.

Prost! Leo Gaggl und das GrowGood-Team