nicht angemeldet
Rolf bWas Du da beschreibst, ist eine Form der deklarativen Programmierung. Du definierst Regeln und Aktionen, und ein Runtime-System arbeitet bei jeder Aktivität im Shop die Regeln ab. Ist eine Regel wahr, werden die anhängenden Aktionen ausgelöst.
Das Verarbeiten der Aktionen bedeutet wiederum Aktivität im Shop, was dazu führt, dass die Regeln geprüft werden müssen, und wieder Aktionen getriggert werden. Ad infinitum, wenn man einen Fehler macht...
Sowas habe ich bei Expertensystemen schon mal gesehen. Es gibt Regeln, Aktionen, und eine Inferenzmaschine, die daraus die erforderlichen Abläufe bestimmt und ausführt.
Ob es fertige Shops gibt, die so ein Bausteinsystem unterstützen, weiß ich nicht. Es sei denn, der Webshop war ein abstraktes Beispiel und Du willst in Wahrheit was ganz anderes bauen.
Um es selbst zu bauen, brauchst Du eine Möglichkeit, deine Regeln und Aktionen so in der DB zu speichern, dass Du sie SICHER interpretieren kannst. Das kannst Du so machen, dass Du Regeln vordefinierst und in der DB nur den Namen der Regel sowie ggf. Parameterwerte speicherst. Z.B. (RegelId=815, Produkt=4711, Regel="PrüfeBestandSchwelle", Parameter1="10", Priorität=1). Die Priorität ist wichtig, ggf. müssen manche Regeln vor anderen beachtet werden. Für jede Regel-ID gibt es dann 1-N Einträge in der Aktionen-Tabelle; ebenfalls per Aktionsname, Parametern und Priorität. Die Aktionen zu den Namen hältst Du dann wieder fertig ausprogrammiert bereit. Für sowas bieten sich Familien aus Klassen an, die ein gemeinsames Regel- oder Aktions-Interface haben.
Das Ganze ist aber nicht trivial, z.B. deine Bestellbestätigung oder Storno-Mail sollte ja nur einmal rausgehen und bei 5 bestellten oder stornierten Produkten nicht fünfmal. D.h. Du brauchst auch ggf. so etwas wie ein Gedächtnis (=Variablen im Regelinterpreter).
Rolf