Hallo zusammen,

ich möchte in der Plauderecke eine Architekturdiskussion anstoßen – bewusst ohne konkretes Produkt‑ oder Framework‑Bashing.

Ausgangspunkt ist ein privates Projekt / Showcase, bei dem ich mich gefragt habe:
Wie müsste man Software heute entwerfen, wenn sie 20 Jahre unverändert betreibbar sein soll?

Statt „State of the Art 2026“ habe ich daher ein paar bewusste Gegenentscheidungen getroffen:

• stabiler Kern (PostgreSQL, klar definierte Domänenlogik)
• Service‑Schicht in Go (kompiliert, wenig Abhängigkeiten)
• Zugriff über mehrere sehr unterschiedliche Clients:
– Web (Browser)
– native Clients (C#, C++20)
– Terminal‑Zugriff (TN3270), testbar sogar auf sehr alter Hardware
• Druck/PDF‑Erzeugung nicht über Office‑Reports, sondern über eine textbasierte Build‑Pipeline (groff) in Docker

Der Retro‑Teil ist dabei weniger Nostalgie als Härtetest:
Wenn eine Anwendung über blockorientierte Terminals funktioniert, erzwingt das automatisch klare Datenmodelle und saubere Schnittstellen.

Mich interessiert nicht „retro vs. modern“, sondern die Frage:

Welche Teile heutiger Softwarearchitektur sind wirklich langlebig – und welche sind es nur, weil wir sie alle benutzen?

Wie seht ihr das aus eurer Praxis?
Gibt es aus eurer Sicht Architekturprinzipien, die den letzten 15–20 Jahren tatsächlich standgehalten haben?

Technologiepapier_Manifest_MovieSystem_v1.pdf

Ein sehr spannendes Thema!

Im Paper selbst schreibst du <Ziel ist nicht „anti‑Microsoft/anti‑Apple“ [...]> ich denke dazu, daß es bei dem Ruf nach Langlebigkeit so ist, daß Microsoft-/Appleprodukte dann nur als Clients zum Einsatz kommen können, weil die ja Funktionen/Kompatibilitäten in manchmal in kürzester Zeit abschalten. Dann müsste das ganze Backend als OpenSource gestaltet sein. Hast du dir Project Nomad schon mal angesehen? Das könnte ja ggf. um die von dir gewünschten Funktionalitäten aufgebohrt werden? Ich hatte da letztes Wochenende bisschen mit rumgebastelt, die Idee an sich ist in jedem Fall super.

Danke für den Hinweis auf das Projekt N.O.M.A.D., das geht auf jeden Fall in die Richtung, die ich grundsätzlich gesucht habe.

Allerdings verfolge ich ein paar Ansätze, in denen sich meine Idee bewusst und grundlegend unterscheidet.

Mein Ziel ist vor allem:

a) eine langfristige Architektur – keine kuratierte Tool‑Sammlung

b) Text‑first – also nicht Browser‑first als primärer Zugang

c) Terminal‑ & Retro‑Zugriff: Ich bin noch im Verein aktiv (Atari ST). Dafür gibt es bei vielen modernen Lösungen – auch bei N.O.M.A.D. – naturgemäß keinen Ansatz

d) 20‑Jahre‑Kompatibilität – das ist für mich der wirklich wichtigste Punkt, der bei vielen bestehenden Lösungen leider fehlt

e) austauschbare Clients – für mich ein absolutes Muss‑Kriterium

N.O.M.A.D. halte ich trotzdem für ein sehr spannendes Projekt, gerade als Referenz dafür, wie viel heute offline‑first und Open‑Source möglich ist. Mein Fokus liegt allerdings etwas stärker auf dem architektonischen Grundgerüst als auf einem integrierten Anwendungspaket.

Wie bewahrt man einen Tropfen vor dem austrocknen? ...