Distribution Platform — wie es entstanden ist

Warum überhaupt

Irgendwann hatte ich mehr als ein Produkt, das als Docker-Container beim Kunden läuft. Und jedes Mal die gleiche Frage: Welcher Kunde darf welche Version, welche Module sind freigeschaltet, wie kommt das Image überhaupt auf seinen Server? Ich habe das anfangs pro Produkt zusammengefrickelt — und es jedes Mal bereut.

Also wollte ich einen Ort, der das zentral weiß: Kunden, Produkte, Module, Lizenzen. Die Kundeninstanz fragt zur Laufzeit „Was darf ich?" und bekommt eine komplette Antwort zurück. Kein Kunden-Self-Service, kein Schnickschnack — ein Admin-Werkzeug, das mir die Buchhaltung über meine eigenen Auslieferungen abnimmt.

Wie es entstand

Ich bin nicht direkt in den Code gesprungen, sondern erst über ein Fachkonzept und eine Reihe von Architecture Decision Records. Das klingt nach Overhead, hat mir aber den Scope vom Hals gehalten: erst der Lizenzserver und das nackte CRUD für Kunden/Produkte/Module/Lizenzen, dann Schicht für Schicht alles andere.

• Ein kleines CRM, weil ich mir zu jedem Kunden Notizen und Wiedervorlagen machen wollte.
• Anbindung an meine Support-Ticket-Lösung, damit Tickets beim richtigen Kunden landen.
• Ein Statistik-Dashboard, das mir read-only zeigt, welche Versionen und Module draußen wirklich laufen.
• Ein optionales Kunden-Portal mit Magic-Link-Login — read-only, single-use, mit Rate-Limit.
• Ein Onboarding-Mailer, der Zugangsdaten verschickt.

Das Herzstück ist die Anbindung an meine Container-Registry: Bei der Anlage eines Kunden wird automatisch ein Robot-Account provisioniert, der genau seine Images ziehen darf — nicht mehr.

Was gut lief

• Die saubere Schichtung (API → Service → Repository → Domain) hat sich ausgezahlt, sobald die zweite und dritte Integration dazukam.
• Optionale Dienste laufen im „Disabled-Mode", wenn man sie nicht konfiguriert. So bleibt das Ding auch ohne Registry, Ticketsystem und SMTP startklar.
• Soft-Delete und ein durchgängiges Audit-Log überall — bei Lizenzen will man nachträglich wissen, wer wann was geändert hat.
• Echte Postgres-Container in den Integrationstests statt Mocks. Findet die Fehler, die zählen.

Was nicht so gut lief

• Der Scope wächst fast von selbst: CRM, Support, Portal, Mailer — jedes für sich sinnvoll, zusammen schnell viel. Ohne die ADRs als Bremse wäre es ausgeufert.
• Die Registry-Integration war fummeliger als gedacht. Robot-Account-Lebenszyklus, der Scan-Report aus dem Schwachstellen-Scanner, null-tolerante Abfragen — viele kleine Kanten.
• Security-Hardening ist nie „fertig": eine veraltete Krypto-Bibliothek rausgeworfen, Images verschlankt, Scan-Gate scharf gestellt. Das bleibt Dauerarbeit.