Modul-Erweiterbarkeit

dForge-Module sind darauf ausgelegt, sich zu kombinieren — nicht geforkt zu werden. Sie können Felder, Ansichten, Aktionen und modulübergreifende Logik auf Module aufsetzen, die Sie nicht geschrieben haben — und trotzdem deren Updates übernehmen. Drei Mechanismen machen das möglich: Abhängigkeiten, Erweiterungsspalten und Bridge-Module.

Abhängigkeiten

Die manifest.json jedes Moduls deklariert die Module, die es benötigt. admin ist immer erforderlich; den Rest wählen Sie. Hängt ein Modul von einem anderen ab, darf es dessen Entitäten, Rollen und Einstellungen referenzieren — so baut ein Finanzmodul auf der geteilten Kundenidentität in parties auf, statt sie neu zu definieren.

Abhängigkeiten sind versioniert: Eine Installation löst den gesamten Baum auf und verweigert Kombinationen, die die Constraints der Module nicht erfüllen.

Erweiterungsspalten

Sie können einer Entität, die einem anderen Modul gehört, Spalten hinzufügen — ohne dieses Modul zu verändern. Die Zusatzspalten leben in einer separaten 1:1-Tabelle, die am Basisdatensatz hängt; der Query-Builder JOINt sie automatisch, sodass sie wie native Felder erscheinen.

Da Ihre Ergänzungen nie die Tabellen des Basismoduls berühren, kann das Basismodul eine neue Version ausliefern, und Ihre Erweiterung läuft weiter. Beispiel: CRM legt industry, credit_limit und account_manager auf den geteilten parties-Datensatz, ohne ihn zu besitzen.

Bridge-Module

Ein Bridge-Modul verbindet zwei Module und ergänzt die Logik, die nur Sinn ergibt, wenn beide installiert sind. Es hängt von beiden ab, erweitert Entitäten aus jedem und steuert neue Aktionen oder Lookups bei.

Echte Beispiele aus dem Katalog:

• crm-fin — Angebot-zu-Rechnung-Umwandlung, Rechnungs-Lookups auf Angeboten, Kreditlimit-Prüfungen über CRM und Finanzen.
• wms-fin — Bestellung-zu-Beleg-Umwandlung und Lieferanten-Lookups über Lager und Finanzen.
• crm-pricing / wms-pricing — eine „Preise aktualisieren“-Aktion, die aus dem Pricing-Modul zieht.

Installieren Sie die Bridge nur, wenn Sie beide Seiten betreiben; deinstallieren Sie sie, und die Basismodule bleiben unberührt.

Warum das besser ist als Forken

Ein Modul zu forken, um es zu ändern, bedeutet, keine seiner künftigen Fixes und Funktionen zu erben. Es zu erweitern bedeutet:

• Upgrade-sicher — aktualisieren Sie eines der Basismodule, und Ihre Erweiterung/Bridge läuft weiter.
• Kombinierbar — jeder Mandant stellt seinen eigenen Stack zusammen; einer betreibt CRM + Finanzen + Bridge, ein anderer Lager + Pricing.
• Prüfbar — Ihre Ergänzungen sind eigene Metadaten, die Sie lesen, diffen und versionieren können, getrennt von den Modulen, auf denen Sie aufbauen.

Drei Stufen, eine Laufzeit

Systemmodule (von dForge gepflegt), Community-Module und Ihre eigenen Custom-Module laufen auf derselben Engine mit demselben Erweiterungsmodell. Ein Custom-Modul erweitert ein Systemmodul genauso, wie ein Systemmodul ein anderes erweitert.

Verwandt

• Was ist ein Modul? — das Modulmodell und der Katalog
• Module Studio — Module visuell bauen und erweitern
• Kernkonzepte — Entitäten, Referenzen, Rollen und Abhängigkeiten