Modulare Architektur inkl. Datenbank

Hallo,

ich habe viele Artikel zu modularer Programmierung gelesen, aber noch keinen guten Ansatz für eine modulare Architektur bis runter auf die Datenbank-Ebene gefunden.

Sollte man ein modulares System überhaupt bis auf die Datenbank-Ebene modular halten? Es wäre eben praktisch, wenn das Modul auch selbständig seine Tabellen und Beziehungen auch aktualisieren könnte. Problemtisch sehe ich darin, dass andere Module, die nicht untereinander abhängig sein sollen, dadurch keinen Zugriff auf Tabellen der kompletten Datenbank bekommen können für z.B. einfache modulübergreifende SQL-Abfragen. Weiterhin müsste man wohl bei Tabellen in unterschiedlichen Modulen auf die Fremdschlüsselverweise verzichten.

Den modularen Ansatz von PRISM finde ich gut. Gibt es etwas ähnliches auch für die Datenbank-Ebene?

Ich würde mich über ein paar neue Denkanstöße sehr freuen.

Sollte man ein modulares System überhaupt bis auf die Datenbank-Ebene modular halten?

Kommt auf die Anforderung und den Zweck an; bekommt man aber in .NET dank ADO.NET relativ gut geschenkt.

Es wäre eben praktisch, wenn das Modul auch selbständig seine Tabellen und Beziehungen auch aktualisieren könnte. Problemtisch sehe ich darin, dass andere Module, die nicht untereinander abhängig sein sollen, dadurch keinen Zugriff auf Tabellen der kompletten Datenbank bekommen können

Module sollten auch wirklich getrennt sein; sonst macht das ja wenig sinn.
Daher dürfen auch keine übergreifende Zugriffe ausgeführt werden.

Wenn man das etwas weiter denkt, dann entspricht das in größeren Umgebungen einer Microservice Architektur.
Jeder Microservice (in Deinem Fall ein Modul) muss vollkommen autoark laufen und darf keine Abhängigkeiten haben.
Ansonsten hast Du immer eine starke Bindung an ein anderes Modul und nimmst Dir damit selbst Flexibilität und Erweiterbarkeit.

Redundanzen sind in diesem Fall durchaus gewollt.

Wenn man das etwas weiter denkt, dann entspricht das in größeren Umgebungen einer Microservice Architektur.
Jeder Microservice (in Deinem Fall ein Modul) muss vollkommen autoark laufen und darf keine Abhängigkeiten haben.
Ansonsten hast Du immer eine starke Bindung an ein anderes Modul und nimmst Dir damit selbst Flexibilität und Erweiterbarkeit.

Mit Microservices oder ähnlichem hat man allerdings Probleme mit übergreifenden Transaktionen. Übergreifende Transaktionen wären für mich aber wichtig. Man bräuchte eine Zwischenlösung. Anstatt eine komplette Trennung der Datenbank bzw. Tabellen wäre evtl. auch eine Abstraktion z.B. über Table per Type (TPT) eine Möglichkeit, sodass den Modulen zumindest die Grundstruktur bekannt ist.

Mit Microservices oder ähnlichem hat man allerdings Probleme mit übergreifenden Transaktionen.

Kommt drauf an, was Du damit meinst.
Bei Micro Services gibt es die Grundregel, dass es niemals eine gemeinsame Datenbank gibt.
Das ist stets der erste Schritt in die starke Bindung.

Übergreifende Transaktionen wären für mich aber wichtig.

Hört sich an, dass Du ein stark abhängiges System bauen willst, das aber Modular ist.
Eierlegende Wollmilchsau?

Anstatt eine komplette Trennung der Datenbank bzw. Tabellen wäre evtl. auch eine Abstraktion z.B. über Table per Type (TPT) eine Möglichkeit, sodass den Modulen zumindest die Grundstruktur bekannt ist.

Damit hast Du eine extrem starke Bindung. Sowohl logisch, wie auch konzeptionell (Datenbanktechnologie).
Dann kannst im Endeffekt auf die Module verzichten - oder die Module dürfen (zB wie bei Wordpress) sich Tabellen teilen, was natürlich ein Sicherheitsthema ist.

Eine ganz spontane Idee, ohne dass ich viel darüber weiß:

Es gibt die TransactionScopes, die mehrere Connections verwalten können.

Wäre es nicht eine Möglichkeit, dass jedes Modul einen eigenen Datenbank-User bekommt, der in seinen Rechten so weit eingeschränkt ist, dass er nur das tun darf, was er können muss?
Der User eines Users darf also nur die Tabellen von dem Modul selber und die zwingend benötigten Tabellen der Haupt-Anwendung oder anderen Modulen lesen/schreiben.
So hätte man alles in einer Datenbank vereint und kann die Vorteile von z.B. ForeignKeys nutzen.

Alternativ könnte man auch zwei verschiedene Datenbanken nebeneinander legen. Damit fliegen Vorteile von einer gemeinsamen Datenbank raus, allerdings hat man auch die starke Bindung nicht mehr.

Der entscheidende Punkt ist aber, dass der TransactionScope dafür sorgt, dass man die Transactions von mehreren Connections committen oder resetten kann.
Wie gut das am Ende funktioniert, oder ob das überhaupt so funktioniert, wie ich mir das vorstelle, weiß ich allerdings nicht. Du könntest es aber mal ausprobieren, vielleicht passt das ja zu deinen Anforderungen.

Könnte man dann nicht zusätzlich noch entsprechende (gegen ein Interface implementierte) Services oder Repositories injizieren, die dann die entsprechenden Scopes bei ihren Operationen als optionalen Parameter erhalten können?

Dann bräuchte man auch nicht auf die anderen Tabellen direkt zugreifen können.

pinki, das ist ja das Basis-Pluginsystem.
Wenn aber eigene Module eigene Dinge speichern sollen, dann bleibt Dir entweder eine eigene DB-Schnittstelle - oder im Endeffekt ein typenloses Konstrukt.

Damit hast Du eine extrem starke Bindung. Sowohl logisch, wie auch konzeptionell (Datenbanktechnologie).
Dann kannst im Endeffekt auf die Module verzichten - oder die Module dürfen (zB wie bei Wordpress) sich Tabellen teilen, was natürlich ein Sicherheitsthema ist.

Meinst du mit Modulen bei Wordpress die Plugins? Mich würde interessieren, ob bzw. wie man bei Wordpress das Problem gelöst hat, dass Zeilen einer eigenen (Modul-)Tabelle, die in logischer Beziehung zu einer Grundtabelle steht, gelöscht werden, wenn die Zeile der Grundtabelle gelöscht wurde (DELETE ON CASCADE). Darf man dort Beziehnungen zu den Grundtabellen aufbauen?

Der entscheidende Punkt ist aber, dass der TransactionScope dafür sorgt, dass man die Transactions von mehreren Connections committen oder resetten kann.
Wie gut das am Ende funktioniert, oder ob das überhaupt so funktioniert, wie ich mir das vorstelle, weiß ich allerdings nicht. Du könntest es aber mal ausprobieren, vielleicht passt das ja zu deinen Anforderungen.

Mit EF könnte man dies auch mit Cross-context transactions durchführen. Aber das Problem ist eben, dass ich hierfür eine übergeordnete Ebene haben muss, die den Datenbank-Context aller Module kennt, aber keine konkreten Details der Tabellen kennt:

[ DB Shared Context ]
[ Modul1 ] [ Modul2 ]
[ DB1 ]       [ DB2 ] 

Wäre es nicht eine Möglichkeit, dass jedes Modul einen eigenen Datenbank-User bekommt, der in seinen Rechten so weit eingeschränkt ist, dass er nur das tun darf, was er können muss?
Der User eines Users darf also nur die Tabellen von dem Modul selber und die zwingend benötigten Tabellen der Haupt-Anwendung oder anderen Modulen lesen/schreiben.
So hätte man alles in einer Datenbank vereint und kann die Vorteile von z.B. ForeignKeys nutzen.

Aber wer definiert die ForeignKeys zu anderen Tabellen, wenn z.B. ein neues Modul mit neuen Tabellen in das System integriert wird. Dann müsste das Modul vermutlich ähnlich wie bei Wordpress die Grundtabellen des Systems kennen.

Mich würde interessieren, ob bzw. wie man bei Wordpress das Problem gelöst hat

WordPress ist Open Source. Darüber hinaus für Entwickler sehr gut dokumentiert.
Feel free.

WordPress hat aber mit Sicherheit keine vollständig getrennte DB, was die Zugriffsebene betrifft.
Wenn überhaupt erstellt WP einen isolierten Context.

Dann müsste das Modul vermutlich ähnlich wie bei Wordpress die Grundtabellen des Systems kennen.

Das sind die gegenläufigen Dinge, die Du willst, die auf Hellsehen hinaus laufen. 😉
Entweder Du gibst Vollzugriff auf alle (System)tabellen, oder Du hast vollständig getrennte Modul-Tabellen/Datenbanken mit Schemaless-FKs.