[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"site-settings-batix":3,"batix-blog-plugin-architektur-die-datenbasis-gehoert-in-die-gemeinsame-library":22,"page-seo-\u002Fblog\u002Fplugin-architektur-die-datenbasis-gehoert-in-die-gemeinsame-library":12},{"id":4,"user_created":5,"date_created":6,"user_updated":7,"date_updated":8,"site_name":9,"site_url":10,"tagline":11,"default_og_image":12,"favicon":12,"organization_legal_name":13,"organization_email":14,"organization_phone":15,"organization_address_street":16,"organization_address_zip":17,"organization_address_city":18,"organization_address_country":19,"social_linkedin":20,"social_xing":21,"social_youtube":21,"social_instagram":21,"google_site_verification":12},"368daec2-c06c-4d64-bba7-feb859b94322","4686f9ba-fccc-4a50-9410-b80ae06ef0eb","2026-05-07T15:29:22.000Z","7d85c00d-d619-4d10-86a2-a469f8283bfc","2026-08-12T12:11:25.000Z","Batix","https:\u002F\u002Fbatix.swiss","Ihr Partner für IT-Beratung, Lösungen und massgeschneiderte Softwareentwicklung in der Schweiz.",null,"Batix Schweiz AG","info@batix.ch","+41 44 545 32 70","Grindlenstrasse 3","8954","Geroldswil","Schweiz","https:\u002F\u002Fwww.linkedin.com\u002Fcompany\u002Fbatix\u002F","",{"id":23,"title":24,"slug":25,"subtitle":26,"category":27,"cover_image":28,"lead_text":29,"definition":30,"content":31,"graphic":32,"graphic_caption":33,"faqs":12,"cta_text":34,"cta_label":35,"cta_url":36,"author":37,"published_at":38,"date_updated":39,"meta_title":40,"meta_description":41,"og_title":12,"og_description":12,"og_image":12,"canonical_url":12,"robots":42},"bf787bc6-8e36-454a-b869-47c14de8972e","Plugin-Architektur: Die Datenbasis gehört in die gemeinsame Library","plugin-architektur-die-datenbasis-gehoert-in-die-gemeinsame-library","Warum Models, Repositories und DAOs besser von Anfang an in einer eigenen Library liegen, statt im ersten Plugin zu landen.","Development","294ba9c3-adaa-44bf-b6e7-13f8624ee7fc","Eine Anwendung beginnt selten mit mehreren Modulen. Zuerst gibt es die App, später kommen ein Export, ein Scheduler oder ein Webportal dazu, und irgendwann fragt jemand im Team: Wo liegt eigentlich der Code, den alle brauchen? Die Antwort entscheidet, ob sich ein neues Modul sauber anschliessen lässt oder ob zuerst ein Umbau ansteht.\n\nBei BX:EDUCATION arbeitet Batix mit einer Plugin-Architektur. Die allgemeine App ist dort ein Plugin, ebenso Module wie Export, Scheduler und das Webportal. Am Anfang lag der datenbanknahe Code allerdings nur in einem davon. Dieser Artikel zeigt, welche Folgen das hatte und welche Teile heute in einer gemeinsamen Library liegen.","Eine Plugin-Architektur teilt eine Anwendung in einen Kern und eigenständige Module, die Plugins, die jeweils einen abgegrenzten Funktionsbereich übernehmen und gemeinsam genutzten Code aus Libraries beziehen.","\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Ein Plugin pro Funktionsbereich\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 8.0pt;\">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.\u003Cbr>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.\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 8.0pt;\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Die Datenbasis gehört in keines der Plugins\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>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.\u003Cbr>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.\u003Cbr>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.\u003C\u002Fp>\n\u003Cp>\u003Cem>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.»\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Was in die Library gehört\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>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.\u003Cbr>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.\u003Cbr>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Der Preis: Die Library wird zum gemeinsamen Vertrag\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>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.\u003Cbr>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.\u003Cbr>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Fazit\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Wer eine Plugin-Architektur plant, sollte die Frage «Was brauchen mindestens zwei Plugins?» stellen, bevor das erste Plugin fertig ist. Die Datenbasis ist dabei meist die erste Antwort. Wird die Library von Beginn an als eigener Baustein angelegt, entfällt der Umbau, den Batix bei BX:EDUCATION im Nachhinein nachholen musste.\u003C\u002Fp>\n\u003Cp> \u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"font-size: 11.0pt; font-family: 'Arial',sans-serif; mso-fareast-font-family: Arial; color: #2e5b7f; mso-ansi-language: DE-CH; mso-fareast-language: DE-CH; mso-bidi-language: AR-SA;\">Häufig gestellte Fragen\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 2.0pt;\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Was ist eine Plugin-Architektur?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 2.0pt;\">Eine Plugin-Architektur teilt eine Anwendung in einen Kern und einzelne Module auf, die Plugins. Jedes Plugin übernimmt einen abgegrenzten Funktionsbereich, zum Beispiel einen Export oder einen Scheduler, und lässt sich unabhängig von den anderen weiterentwickeln.\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 2.0pt;\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Was gehört in die gemeinsame Library?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Alles, was mit der Datenbasis zu tun hat, also Models, Repositories und DAOs, dazu allgemein verwendbare Extensions und Interfaces, etwa für Mapper. Code, der nur einen Funktionsbereich betrifft, bleibt im jeweiligen Plugin.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Warum nicht einfach den Datenbankcode im ersten Plugin lassen?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Sobald andere Plugins denselben Code brauchen, müssen sie ihn entweder kopieren oder vom ersten Plugin abhängen. Beides hebt die Unabhängigkeit auf, die eine Plugin-Architektur eigentlich bringen soll. Dazu kommt, dass Korrekturen an der Datenbasis dann nur noch an einer Stelle nötig sind.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Lohnt sich eine Plugin-Architektur auch für kleine Anwendungen?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>Bei einer einzelnen Anwendung ohne weitere Module steht der Aufwand meist in keinem guten Verhältnis zum Nutzen. Sobald mehrere Funktionsbereiche absehbar sind, sollte die gemeinsame Basis aber von Beginn an eingeplant werden. Der Zusatzaufwand zahlt sich aus, wenn die Anwendung wächst.\u003C\u002Fp>\n\u003Cp>\u003Cspan class=\"tm6\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Welche Plugins gibt es bei BX:EDUCATION?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>Unter anderem die allgemeine App, einen Export, einen Scheduler und das Webportal. Die gemeinsame Datenbasis liegt in einer Library, auf die alle Plugins zugreifen.\u003C\u002Fp>","06efe278-29a7-4fd3-b941-65916aae1351","Alle Plugins greifen auf dieselbe Library mit Datenbasis, Extensions und Mapper-Interfaces zu.","Wer eine wachsende Software in klar getrennte Module aufteilen oder eine bestehende Anwendung auf eine Plugin-Architektur umstellen will, findet in der individuellen Softwareentwicklung der Batix den passenden Ansprechpartner.","Kontakt aufnehmen","\u002Fcontact","Sascha Wechsler","2026-10-30T10:13:00.000Z","2026-10-30T10:13:26.000Z","Plugin-Architektur: Library richtig planen","Sie erfahren, welche Teile einer Plugin-Architektur in eine gemeinsame Library gehören und warum sich die Datenbasis nicht im ersten Plugin versteckt.","index,follow",1793357070266]