Es ist verlockend, bei einem neuen Projekt zuerst das zu bauen, was man sehen kann. Eine Startseite, ein Dashboard, ein paar Karten – und schon fühlt es sich nach Fortschritt an.
Ich habe inzwischen eher das Gegenteil gelernt: Wenn ich zu früh an der Oberfläche hänge, fange ich an, die Struktur darunter passend zur Oberfläche zu verbiegen. Das funktioniert eine Weile. Später rächt es sich.
Erst die Frage: Was ist wirklich der Kern?
Bei größeren Projekten versuche ich zuerst zu klären, was immer da sein muss, was als Modul leben kann, wo die führenden Daten liegen und welche Teile möglichst wenig voneinander wissen sollten.
Bei NextPrivyCore ist das eine der wichtigsten Regeln: Der Core soll schlank bleiben. Funktionen kommen über Module. Verwaltung und eigentliche Nutzung sind unterschiedliche Aufgaben. Und gemeinsame Daten sollen nicht in jedem Modul ihre eigene Wahrheit entwickeln.
Die Oberfläche ist trotzdem wichtig
Ich mag gute Oberflächen. Ich will nachvollziehbare Zustände, verständliche Verwaltungsseiten und im normalen Betrieb möglichst wenig Terminal-Zwang. Aber die Oberfläche darf nicht die Architektur diktieren.
Wenn eine Funktion nur deshalb im Core landet, weil sie auf der Startseite hübsch aussieht, ist das meistens ein Warnsignal.
Eine sauber getrennte Funktion lässt sich testen, austauschen und notfalls wieder entfernen. Ein Monolith ist am Anfang bequem. Später weiß niemand mehr, welche kleine Änderung an welcher Stelle eine völlig andere Funktion kaputtmacht.
Deshalb lieber zuerst tragfähige Grenzen – und danach eine Oberfläche, die daraus etwas wirklich Benutzbares macht.