Ich bin der Meinung, dass genau das der richtige Weg für dein Vorhaben ist.
Ein einheitliches Interface für die DLLs definieren und gut ist.
Genau so habe ich es jetzt auch in meinen ersten Delphi-Wochen bislang hingebogen. Die DLLs führen eigentlich auch nur genau die genannten Funktionen nach außen. Für Notfallzwecke gibt es weiterhin noch ein
get/setValue(propertyName:Str):Str
welches dann über
RTTI in den von der
DLL erstellten Objekten wühlt.
Toll, dass jemand das genauso sieht, dann bin ich wohl doch kein hoffnungsloser Fall
Der
gravierende Schwachpunkt ist allerdings, dass Windows Dinge wie Verbindungshandles und geöffnete Dateien
pro Prozess verwaltet. In meinem Anwendungsfall ist die Anwendung dazu da, Hardware zu steuern. Hat sich ein Programmteil aufgehangen oder ist abgestürzt, kann ich den Speicher zwar wieder brauchbar freiräumen, bekomme aber meine Handles nicht wieder - Ich komme an die Ports nicht mehr dran. Der Kunde kann nicht wegen so etwas den gesamten Betrieb lahmlegen und das ganze Programm herunter- und wieder hochfahren. Daher der Wille zur Multi-Prozess-Architektur. Auch der Internet Explorer und Google Chrome halten das seit Neustem mit ihren Plug-Ins und Tabs ähnlich.
Nun gut, dann halt die Module als eigene Prozesse statt Libraries im selben Prozess. Unterhalte ich mich mit denen halt per x-beliebiger Methode. Eigentlich kein wirklicher Unterschied bis hierhin.
Nun wäre es allerdings auch
zeitgemäß, auch auf anderen Geräten zu sehen (und steuern), was auf der eigentlichen Maschine vor sicht geht - Ohne Eselsbrücken wie TeamViewer
Jetzt habe ich doch schon mehrere Prozesse - Jetzt sollte ich auch dafür sorgen, dass die Prozesse sich gut fernsteuern lassen! Entweder spuckt mir das Modul nun einen Block (
XML) an Dingen aus, die sich bei ihm einstellen lassen, ich bereite das anderswo auf
wie ich lustig bin auf und schicke ihm einen
XML-Block zurück (den es entweder annimmt, nur teilweise oder komplett zurückweist),
oder das Modul bietet nur die interne Logik an ("stellt einen Service bereit"?) den ich dann mittels einer
GUI auf der gleichen Maschine oder anderswo direkt darstellen kann (Präsentationsschicht).
Zusammenfassend scheinen fertig zu kaufende Lösungen wie eben RemObjects oder RealThinClient mir (in meinem konkreten Fall) die Arbeit abzunehmen, wie ich jetzt meine Präsentationsschicht mit der Anwendungsschicht verknüpfe?
Der einzige Grund warum ich damit vielleicht noch hadere, war dass ich bislang nur an reine
VCL-Anwendungen auf einem Windows-System gedacht hatte, die Plug-Ins sich auch selbst um ihre
VCL-Oberfläche gekümmert haben, und gut war. Wenn ich die Darstellung nun aus den Plug-Ins rausziehe, brauche ich für den lokalen Betrieb (95% der Fälle) nun den Kern, seine
n Module und noch einmal
n Präsentationsanwendungen. Und irgendwie wird mir das dann langsam etwas zu viel...
Vielen Dank für die Antworten bislang! 
Ich versuche die Sache nicht zu sehr auszuschmücken um nicht zu viel Zeit zu stehlen.