Hi @christianlupus !
Hilf mir kurz dein Problem zu verstehen - generell funktioniert das ja sehr gut.
Ich wollte kurz teilen, dass man als Nextcloud-App eigene Services/Interfaces bereitstellen kann, die andere Apps nutzen können.
Anders nutze ich ja beispielsweise die Notification App aus meiner Attendance App heraus ja auch nicht - ich lasse einfach per Dependency Injection INotificationManager injizieren und kann dann einfach auf createNotification() bzw. notify() einfach Notifications erstellen, die dann natürlich von der Notifications App verwaltet werden. Siehe attendance/lib/Service/NotificationService.php at main · luflow/attendance · GitHub
Genau so können auch von anderen Apps einfach Interfaces bereitgestellt/registriert werden, die dann von anderen Nextcloud apps genutzt werden können. Vor allem wenn es bei @Wacken2012 um “eigene” verwandte Apps geht, sollte das erst Recht kein Problem sein.
@Wacken2012 den Core sollte man vermutlich gar nicht benötigen, da jede App die eigene Datenhaltung umsetzt und dann per Interfaces einfach Daten ausgetauscht werden.
Und eine die Frage die du dir stellen könntest: Thema Sitzungen/Beschlüsse bzw. Notenverwaltung oder auch Kassenbuch braucht vermutlich nicht unbedingt eigene Apps - da das zu 95% ja über die Files App oder Collabora/LibreOffice abgebildet werden könnte. Eine FiBu-Software in Nextcloud zu bauen ist ja bspw. auch eine ziemliche Mammut-Aufgabe 
Im Grunde ist jedes Feature für sich schon eine ziemlich große Aufgabe, wenn es gut werden soll. Insofern ist es sicher sinnvoll dafür auch jeweils eigene Apps zu bauen. Ob der Datenaustausch dann immer gut funktioniert kann ich aber nicht abschließend beurteilen.
Spannend wäre welches Problem @christianlupus gerade zu knacken versucht, vielleicht gibt uns das Einblick in welche Richtung man weitergehen sollte.