Plugin-Architektur: Die Datenbasis gehört in die gemeinsame Library

In einer Plugin-Architektur übernimmt jedes Plugin einen abgegrenzten Funktionsbereich. Bei BX:EDUCATION gibt es unter anderem die allgemeine App, einen Export, einen Scheduler und das Webportal, jeweils als eigenes Plugin. Der Gedanke dahinter ist einfach: Wer am Export arbeitet, muss den Scheduler nicht im Detail kennen, und ein Funktionsbereich lässt sich ändern, ohne die anderen anzufassen.
Diese Rechnung geht aber nur auf, solange die Plugins wirklich unabhängig bleiben. Sobald mehrere Plugins dieselben Daten brauchen, entsteht die erste Abhängigkeit. Und mit ihr die Frage, wohin der gemeinsame Code gehört. Wer sie nicht früh beantwortet, beantwortet sie später unter Zeitdruck, meist im laufenden Betrieb.

Bei BX:EDUCATION lagen Models und Repositories zuerst nur in einem einzelnen Plugin. Das ist naheliegend, denn das erste Plugin braucht die Datenbank als Erstes. Andere Plugins brauchten denselben Code aber ebenfalls. Ein Export etwa liest dieselben Entitäten wie die App, ein Scheduler greift auf dieselben Daten zu.
Die Kopier-Variante wirkt zu Beginn am schnellsten und wird am teuersten. Wird eine Abfrage in einem Plugin korrigiert, bleibt sie in allen Kopien falsch, bis jemand daran denkt. Die Abhängigkeit vom ersten Plugin wiederum wirkt harmlos, bis ein Plugin plötzlich nur deshalb den halben Funktionsumfang eines anderen mitschleppt, weil es dessen Models braucht.
Im Kern bleiben drei Wege. Man kopiert den Code in jedes Plugin und pflegt danach mehrere Versionen derselben Abfrage. Oder man lässt die anderen Plugins vom ersten abhängen, womit die Unabhängigkeit dahin ist, die man mit Plugins eigentlich wollte. Oder man lagert die Datenbasis in eine gemeinsame Library aus. Bei Batix wurde es die dritte Variante, nur eben im Nachhinein. Jedes Plugin musste dafür einzeln auf die Library umgestellt werden, und das bei laufender Anwendung.

Sascha, der die Architektur für BX:EDUCATION entwickelt und umgesetzt hat:«Die Datenbasis gehört von Anfang an in eine gemeinsame Library. Wir haben sie erst im Nachhinein ausgelagert, und das in alle Plugins zu integrieren, war aufwändig und mühsam.»

In der Library liegt alles, was mit der Datenbasis zu tun hat: Models, Repositories und DAOs. Dazu kommen Extensions, die sich allgemein gut verwenden lassen, und Interfaces, etwa für Mapper. Die Models bilden die Datenbank-Entitäten eins zu eins ab, und die Repositories nutzen ein gemeinsames AbstractRepository für wiederkehrende Abfragen, wie im Artikel zur Schichtenarchitektur beschrieben.
Interfaces für Mapper zeigen gut, wie die Abgrenzung gemeint ist. Das Interface legt fest, wie zwischen Model und DTO übersetzt wird, und liegt in der Library, damit alle Plugins dieselbe Vorgabe verwenden. Was ausschliesslich einen Funktionsbereich betrifft, bleibt dagegen im jeweiligen Plugin.
Für neuen Code helfen drei Fragen bei der Zuordnung. Betrifft er die Datenbasis? Braucht ihn mehr als ein Plugin? Lässt er sich allgemein verwenden? Bei jedem Ja gehört er in die Library, sonst bleibt er dort, wo er entsteht. Die Abgrenzung muss nicht perfekt sein, sie muss im Team bekannt sein. Dann lässt sich auch ein Grenzfall in wenigen Minuten klären.

Eine gemeinsame Library löst das Duplikat-Problem, schafft aber eine neue Abhängigkeit. Eine Änderung an einem Model kann jedes Plugin betreffen, das es verwendet. Wer die Library pflegt, geht mit Änderungen deshalb vorsichtiger um als im Code eines einzelnen Plugins.
In der Praxis heisst das: Änderungen laufen zuerst durch die Library und werden dann in den Plugins nachgezogen, die davon betroffen sind. Wer das konsequent so handhabt, erkennt Auswirkungen früh, statt sie erst beim Zusammenspiel der Plugins zu bemerken.
Das ist ein bewusster Tausch: weniger Duplikate, dafür zentrale Verantwortung. Er lohnt sich, sobald mehr als ein Plugin dieselben Daten braucht, und das ist in einer wachsenden Anwendung früher der Fall, als man zu Beginn annimmt. Eine einzelne Anwendung ohne weitere Module braucht diese Struktur dagegen nicht.