Formular im Portal
- Eingang
- Rabatt 40 % im Formular
- Regel
- quote.discount: 40 > 15, abgelehnt
- Anzeige
- „Über 15 % braucht Freigabe“
- Ergebnis
- Nichts gespeichert
TypeScript & Node.js
Eine Geschäftsregel steht bei mir einmal im Code und gilt dann überall.
Dieselbe Regel an drei Türen
Jemand trägt 40 Prozent Rabatt ein. Was dann passiert, hängt nicht davon ab, wo die Zahl hereinkommt.
Schnittstelle
- Eingang
- POST /quotes mit Rabatt 40 %
- Regel
- quote.discount: 40 > 15, abgelehnt
- Protokoll
- warn quote.discount 40
- Ergebnis
- Antwort 422, nichts gespeichert
Tabellen-Import
- Eingang
- Zeile 114: Rabatt 40 %
- Regel
- quote.discount: 40 > 15, abgelehnt
- Protokoll
- warn quote.discount 40, Zeile 114
- Ergebnis
- Zeile übersprungen, 249 von 250 übernommen
Beispielwerte. Welche Grenze bei Dir gilt, legst Du fest. Ich schreibe sie einmal auf.
Die Regel dahinter
Hier steht sie, Zeile für Zeile erklärt. Die Grenze steht einmal im Code, und alle drei Türen lesen sie von dort.
import { z } from 'zod';// Prozent. Darüber entscheidet ein Mensch.export const MAX_DISCOUNT = 15;export const QuoteLine = z.object({ item: z.string().min(1), quantity: z.number().int().min(1), discount: z.number().max(MAX_DISCOUNT),});Die Regel steht einmal.
Die Grenze von 15 Prozent steht in Zeile 4 und nirgends sonst. Ändert sie sich, ändere ich diese eine Zeile, und Formular, Schnittstelle und Import folgen.
Zeilen 1 bis 10
// Formular, Schnittstelle und Import:const result = QuoteLine.safeParse(input);if (!result.success) { return reject(result.error);}Falsche Eingaben stoppen an der Tür.
Jede Stelle, die Daten annimmt, ruft dieselbe Prüfung auf. Eine falsche Zahl kommt gar nicht erst in die Datenbank, also muss sie später auch niemand in einer Auswertung suchen.
Zeilen 11 bis 15
function reject(error: z.ZodError) { log.warn('quote.discount', error.issues); return { status: 422, message: 'Über 15 % braucht Freigabe', };}Der Fehler geht ins Protokoll.
Die Prüfung schreibt den Vorfall mit der Regel und dem Wert ins Protokoll. Der Nutzer bekommt einen Satz, den er versteht, und keine technische Fehlerseite.
Zeilen 16 bis 22
test('über der Grenze scheitert', () => { const line = { item: 'A', quantity: 1 }; const bad = { ...line, discount: 16 }; expect(QuoteLine.safeParse(bad).success) .toBe(false);});Ein Test hält die Grenze fest.
Der Test prüft den Wert direkt über der Grenze, nicht die Formulare davor. Wer die Grenze später verschiebt, stößt auf diesen Test und muss die Änderung bewusst bestätigen.
Zeilen 23 bis 28
Wofür ich es einsetze
- Individuelle Geschäftslogik hinter einem Portal
- Rechen- und Angebotslogik für Vertriebsprozesse
- Import- und Exportstrecken für Bestandsdaten
- Rollen- und Rechtemodelle für mehrere Mandanten
- MVPs, die später ein internes Team übernimmt
Wo es schon läuft
- 2026
- 2025
- 2025
In diesen Angeboten steckt es
04
Full-Stack Development
Eine Funktion, ein System, ein Verantwortlicher.
2–12 Wochen, Festpreis nach technischem Check
05
Portal & Individualsoftware
Aus Dienstleistung wird ein digitales Erlebnis.
6–12+ Wochen, Bau und Betrieb, nach der Discovery
Welche Regel läuft bei Dir auseinander?
Schildere mir den Fall in drei Sätzen. Ich antworte selbst, und das Gespräch dauert 15 Minuten.
Erstgespräch buchen
Oder direkt: info@coderconda.com
Davor: drei Sätze, zwei Werktage bis zur Antwort, 15 Minuten Gespräch. So beginnt es