Architektur on markob.de

Das Framework ist nur ein Detail. Das Domainmodell ist es nicht.

Mon, 24 Aug 2026 00:00:00 +0000

In Das Framework ist nur ein Detail war unsere These: Neue Anwendungslogik sollte nicht davon abhängen, ob am äußeren Rand Yii, Slim oder ein anderes Framework HTTP-Requests verarbeitet. Das Framework sollte Adapter sein, nicht Architektur.

Daran hat sich nichts geändert. Inzwischen beschäftigt uns allerdings eine Frage, die noch eine Ebene tiefer geht: Wenn wir das Framework aus dem Zentrum von LimeSurvey entfernen – welches Domainmodell wollen wir dort eigentlich erhalten? Begriffe wie QuestionGroup, Question, SubQuestion oder QuestionType sind für LimeSurvey-Entwickler so selbstverständlich, dass man leicht vergisst, sie überhaupt noch infrage zu stellen. Aber sind das notwendige Konzepte eines Survey-Systems – oder historische Architekturentscheidungen, die uns heute nur deshalb wie Domainlogik erscheinen, weil LimeSurvey seit vielen Jahren so funktioniert?

Das Framework ist nur ein Detail

Fri, 21 Aug 2026 00:00:00 +0000

In einer LimeSurvey-Stellenanzeige für einen Full-Stack-Developer (Stand: 20. August 2026) taucht unter „Tech We Use" das „Yii-3 PHP Framework" auf – bemerkenswert, denn der aktuelle LimeSurvey-Core basiert weiterhin auf Yii 1.1. Ob damit der bestehende Core migriert werden soll, ob Yii3 nur für neue Komponenten gedacht ist oder ob lediglich einzelne Yii3-Pakete gemeint sind, wissen wir nicht. Für das Folgende spielt das auch keine große Rolle.

Denn bevor LimeSurvey entscheidet, welches Framework Yii 1.1 irgendwann ersetzt, lohnt sich eine andere Frage: Warum sollte diese Entscheidung für den Anwendungscode überhaupt von Bedeutung sein?

Das LimeSurvey Plugin-Event-System – eine kritische Betrachtung

Sat, 09 May 2026 00:00:00 +0000

LimeSurvey verfügt über ein event-basiertes Plugin-System. Plugins abonnieren Events, reagieren darauf, und können Daten zurückgeben. Das Konzept ist solide – und weit verbreitet in modernen Frameworks. Die Implementierung erzählt eine andere Geschichte.

Was ein Event-System leisten soll

Ein Event kommuniziert, dass etwas passiert ist oder passieren wird. Der Name beschreibt das Ereignis. Die Parameter sind bekannt und garantiert. Der Empfänger reagiert – er fragt nicht erst nach, ob die Daten überhaupt vorhanden sind.

SurveyIndex + SurveyRuntimeHelper – Anatomie eines God Flow

Wed, 06 May 2026 00:00:00 +0000

Wenn zu viel Verantwortung nicht in einer Klasse steckt, sondern in einem Ablauf

In den letzten Artikeln dieser Serie haben wir zwei bekannte Antipattern betrachtet: createFieldMap() als Beispiel einer Funktion, die zu viele Verantwortlichkeiten in sich vereint, und LimeMailer als Beispiel einer Klasse, die zu viel weiß, zu viel hält und zu viel tut. Beide Diagnosen folgten derselben Logik: Zu viel Verantwortung an einer Stelle.

Diesmal geht es um etwas anderes. Nicht eine Funktion. Nicht eine Klasse. Sondern einen Ablauf.

createFieldMap() – die God Function

Sun, 26 Apr 2026 00:00:00 +0000

Im Artikel über die Helper-Funktionen haben wir common_helper.php als Ganzes betrachtet – 130+ globale Funktionen, über 11.000 Aufrufe im Code, ein Relikt aus der prozeduralen Ära. In einem anderen Artikel haben wir LimeMailer als GodClass analysiert: eine Klasse die zu viel weiß, zu viel tut, und deshalb praktisch nicht testbar ist.

Heute schauen wir auf etwas das noch subtiler ist: eine GodFunction.

Keine Klasse. Eine einzelne Funktion. Mit über 600 Zeilen Code.

LimeSurvey und die Helper-Funktionen

Sun, 29 Mar 2026 00:00:00 +0000

Wer LimeSurvey als Plugin-Entwickler nutzt oder in der Codebasis arbeitet, begegnet früher oder später diesem Muster:

Yii::app()->loadHelper('common');
Yii::app()->loadHelper('surveytranslator');
Yii::app()->loadHelper('replacements');

Dahinter steckt ein einfacher Mechanismus: loadHelper('common') lädt die Datei application/helpers/common_helper.php und macht ihre Funktionen im globalen Scope verfügbar. Dasselbe Muster findet sich auch bei loadLibrary(), das auf application/libraries/ zeigt:

public function loadHelper($helper)
{
 Yii::import('application.helpers.' . $helper . '_helper', true);
}

public function loadLibrary($library)
{
 Yii::import('application.libraries.' . $library, true);
}

Der konzeptuelle Unterschied zwischen Helper und Library ist dabei in der LimeSurvey-Codebasis kaum greifbar – beide Mechanismen lösen dasselbe Problem auf dieselbe Art. Das war in einer Zeit sinnvoll, als PHP noch kein Autoloading kannte und Funktionen manuell eingebunden werden mussten. PHP 5.1 war 2005. Composer erschien 2012.

LimeMailer - Anatomie einer God Class

Sun, 22 Mar 2026 00:00:00 +0000

LimeMailer ist die zentrale E-Mail-Komponente von LimeSurvey. Sie erbt von PHPMailer, der weit verbreiteten PHP-Mailer-Bibliothek, und erweitert diese um LimeSurvey-spezifische Logik: Umfrage-Templates, Token-Ersetzungen, Anhänge nach E-Mail-Typ, Plugin-Events und vieles mehr.

Dieser Artikel betrachtet die Klasse nicht als Fehler ihrer Entwickler. Wer in einem laufenden Open-Source-Projekt unter Zeitdruck Features liefert, trifft Entscheidungen, die im Moment vernünftig sind. Technische Schulden entstehen nicht durch Unwissenheit, sondern durch die Realität von Softwareentwicklung. Was hier analysiert wird, ist das Muster – nicht die Person dahinter.

LimeSurvey - ein System im Übergang

Sun, 01 Mar 2026 00:00:00 +0000

Was ist LimeSurvey?

LimeSurvey gehört seit vielen Jahren zu den meistverbreiteten Open-Source-Umfragelösungen im PHP-Ökosystem. Die Plattform ermöglicht die Erstellung, Verwaltung und Auswertung von Online-Umfragen und richtet sich sowohl an einzelne Anwender als auch an Organisationen mit komplexen Anforderungen. Mit einer großen aktiven Installationsbasis und kontinuierlicher Weiterentwicklung ist LimeSurvey ein Projekt, das seit langem produktiv eingesetzt wird. Für Umfragen im akademischen oder organisatorischen Kontext gibt es kaum eine vergleichbare Open-Source-Alternative mit diesem Funktionsumfang.