Anwendung entwickeln für zu Hause – eine Finanzverwaltung

Mein Quicken ist in die Jahre gekommen. Mag ich das aber wirklich erneuern, schließlich arbeite ich als Software-Entwickler? Da reift die Überlegung eine Anwendung selbst zu entwickeln.

Die Anforderungen der Anwendung

Bevor ein erster Prototyp entsteht, gilt es erst mal einfache Anforderungen zusammen zu tragen.

Was sollte ein erster Prototyp können? Eine einfache Tabelle mit Datum, Beschreibung und Betrag reicht nicht. Das wäre praktisch ein Kassenbuch. Ich habe dann doch mehr als ein Konto und – Hand aufs Herz – ein Kassenbuch geht mit jeder Tabellenkalkulation.
Die doppelte Buchführung sollte es schon sein. Das ist es in Quicken auch, die Gegenkonten heißen dort halt nur Kategorie. Mehrteilige Buchungen sollten auch möglich sein. Vom Giro-Konto buchen beispielsweise die Stadtwerke ab, der Betrag setzt sich dabei aus den Strom- und den Gas-Kosten zusammen. Wollte ich einen Vergleich dieser Kosten für alternative Anbieter machen, müßte ich das schon trennen können.

Die Modellierung ist nicht neu. Was auf der Arbeit funktioniert, gilt auch für die Software zu Hause: das Rad nicht neu erfinden. Zumindest ist das Datenmodell schon da – zumindest im Prinzip. Martin Fowler hat sich schon vor einiger Zeit Gedanken dazu gemacht: https://martinfowler.com/eaaDev/AccountingNarrative.html

Das Datenmodell

Die erste Wurf für das Modell der Anwendung sieht wie folgt aus. Das ist eine eingedeutschte Variante des Fowler-Vorschlages.

Klassenmodell
Klassenmodell der Anwendung

Die gute doppelte Buchführung: eine Buchung ist immer Soll an Haben oder als Text-Format: “Per Soll-Konto, Betrag an Haben-Konto, Betrag”, wobei es jeweils mehrer Soll- und Haben-Konten geben kann. Die Summe der Soll und Haben-Beträge muss 0 sein. Soll-Beträge sind positiv und Haben-Beträge negativ. Das entspricht dem gewohnten Gefüge, dass Guthaben positiv sind und Schulden negativ.

Die Buchung fasst die (Konto-)Umsätze zusammen. Jeder Umsatz kennt seine Buchung – kann ohne diese auch gar nicht existieren – und er kennt das Konto, welches er anspricht.

Der Saldo des Kontos ergibt sich formal als die Summe der Beträge aller Umsätze des Kontos. Fraglich ist, ob der immer aufs Neue berechnet wird oder der letzte Stand gespeichert ist. Im Unternehmen wäre die Antwort das speichern des Saldos, da die Berechnung auf sehr viele Umsätze zu lange dauert und im Verlauf der Zeit immer länger. Ich lasses es dabei.

Erste Anwendungsfälle der Anwendung

Die folgenden Anwendungsfälle mag ist initial umsetzten:

  • Buchen erstellen
    Das ist praktisch das Aufbauen des Hauptbuches. Initial mag ich ein abgesprochenes Konto automatisch anlegen, wenn es noch nicht existiert. Das spart erst mal einen Anwendungsfall “Konto anlegen”.
  • Konten abfragen
    Ich bekomme eine Liste aller existierenden Konten mit deren aktuellen Salden. Das ist praktisch das Grundbuch.
  • Umsatz anzeigen
    Zuletzt mag ich noch die Umsätze eines Kontos ansehen können. Hier sind die Details sichtbar, um zum Beispiel Ausgaben zu vergleichen oder Positionen zu kontrollieren.

Die technische Basis – ein erster Ansatz

Finanzdaten mag ich nicht unnötig offen haben, also ist der private Rechner meine Zielplattform. Was liegt näher als das für eine kaufmännische Anwendung gewohnte Setup zu wählen.

Auf einem Rechner einen Browser für die Anwendung? Warum nicht, denn was ist mit HTML, CSS und Javascript nicht machbar. Diesen Ansatz verfolgt beispielsweise das Project Electronjs. Hier kommt vollständig Javascript zum Einsatz und es entsteht eine ausführbare Binärdatei, die für unterschiedliche Betriebssysteme erstellt werden kann.

Nun bin ich in – gerade was die Fachlogik angeht – mehr in der Java-Welt zu Hause. Dank der Graal VM ist auch hier mal eine kompilierte Version denkbar und die Entwicklung geht schneller von der Hand.

Aus der täglichen Gewohnheit mag ich mit den Mitteln arbeiten, die ich bereits gut kenne. Das bedeutet: relationale Datenbank, Spring Boot als Backend und Angular für die Oberfläche.

Natürlich bleibt das ganze zu überdenken. Für den Zugang ist ein Browser mit der entsprechenden URL zu starten. Das ist allerdings lösbar.

Für die Datenbank bietet sich eine eingebundene (embedded) Variante an, um zusätzliche Installationen zu vermeiden, z.B. H2.
Da das Datenmodell auf der “grünen Wiese” entsteht, möchte ich als Anbindung an die Datenbank die Java Persistente API (JPA) nutzen, da JPA das Schema direkt erstellen kann und somit Arbeit spart.

Die nächsten Schritte zur Anwendung

Im nächsten Beitrag beschreibe ich zunächst die Schnittstelle des Backends, welches die umzusetzenden Anwendungsfälle darstellt.

Dann schau ich mir die zugehörige Implementierung an. Da steckt etwas Forschung drin. Denn diese Anwendung ist nicht für ein großes Finanzunternehmen gedacht. Im Sinne des KISS-Prinzips gibt es vielleicht Alternativen.

Bis dahin: Happy coding!

Ein Gedanke zu „Anwendung entwickeln für zu Hause – eine Finanzverwaltung“

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.