Ein Modul, das es so noch nicht gibt
Nicht jede Sonderanforderung braucht gleich eine eigene Anwendung. Sehr oft ist
die richtige Antwort schlicht ein Modul — nur eben eines, das es fertig nicht
gibt: dein Rabattmodell, deine Freigabelogik, dein Bestellprozess, deine Regeln
für Versandkosten oder Mindestbestellmengen. Genau das planen und bauen wir,
zugeschnitten auf deinen Ablauf statt auf den kleinsten gemeinsamen Nenner
eines Marktplatz-Plugins.
Technisch gelten dabei dieselben Regeln wie für unsere
Katalog-Module: keine Core-Eingriffe, saubere
Erweiterungspunkte des jeweiligen Systems, kein externer Tracker, und eine
Struktur, die ein Systemupdate übersteht. Was individuell ist, soll die Wartung
nicht teurer machen als nötig.
Wie so ein Modul entsteht:
- Anforderung gemeinsam durchsprechen — meist ist der beschriebene Wunsch nicht ganz das eigentliche Problem
- Konzept mit Funktionsumfang, Backend-Oberfläche und Aufwandsschätzung, bevor Code entsteht
- Umsetzung in Schritten, jeder Stand auf einer Testumgebung nachvollziehbar
- Übergabe mit Dokumentation und Quellcode — das Modul gehört dir
- Auf Wunsch Pflege und Anpassung bei künftigen Shop-Updates
Wenn sich unterwegs zeigt, dass eine Funktion auch für andere Shops taugt, wird
daraus manchmal später ein Standardmodul. Dein individueller Teil bleibt davon
unberührt — und Vorrang hat immer dein Anwendungsfall, nicht die Katalogtauglichkeit.
Warum eigene Middleware statt Direktanbindung?
Die schnellste Lösung ist fast immer, den Shop direkt mit dem Zielsystem sprechen zu
lassen. Das funktioniert — bis das andere System langsam wird, ein Feld umbenennt
oder für zwei Stunden nicht erreichbar ist. Dann steht der Checkout, und niemand
weiß, welche Bestellung übertragen wurde und welche nicht.
Eine eigene Schicht dazwischen nimmt Vorgänge an, bestätigt sie sofort und arbeitet
sie eigenständig ab. Fällt ein System aus, laufen die Aufträge in eine Warteschlange
statt ins Leere. Ändert sich ein Format, wird das an einer Stelle angepasst statt an
fünf. Und weil jeder Vorgang protokolliert wird, lässt sich im Zweifel belegen, was
wann übergeben wurde.
Für solche Dienste setzen wir meistens auf Laravel — die
Bausteine für Warteschlangen, geplante Aufgaben und Protokollierung sind dort
bereits vorhanden, und das Ergebnis lässt sich unabhängig vom Shopsystem betreiben
und aktualisieren. Wenn ein Projekt besser zu Symfony oder zu einem schlanken
eigenen Dienst passt, machen wir das stattdessen.
Wie so ein Projekt abläuft
- Bestandsaufnahme: Welche Systeme sind beteiligt, wo tut es aktuell weh?
- Konzept mit klarer Aufwandsschätzung, bevor Code entsteht
- Umsetzung in nachvollziehbaren Schritten, jeweils auf einer Testumgebung
- Übergabe mit Dokumentation — auch für den Fall, dass jemand anderes weiterarbeitet
Und wenn das Shopsystem selbst das Problem ist?
Manchmal lohnt sich kein weiterer Umbau, weil die Grundlage nicht mehr trägt —
etwa bei Magento 1 oder OpenMage ohne Sicherheitsupdates. Dann ist der
Systemwechsel der ehrlichere Weg. Wie wir Umzüge abwickeln, steht unter
Migration.