• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Künstliche Intelligenz
    • Ein erster AI-Agent für die Softwarearchitektur: Qualitätsziele im Dialog
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
  • IT-Karriere
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Néstor Torres 01. Juli 2026

Konfigurierbare Systeme in der Unternehmenssoftware: Taxonomie, Architektur und Governance

Ein Praxisleitfaden für Architekten, Principal Engineers und CTOs

Konfigurierbarkeit ist in modernen Softwaresystemen längst kein optionales Merkmal mehr. Systeme müssen unterschiedliche Länder, gesetzliche Anforderungen, Kundenvarianten und Integrationsumgebungen unterstützen – häufig auf Grundlage einer gemeinsamen Codebasis.

In der Praxis wird Konfiguration oft als technische Detailfrage behandelt: Datenbank oder Datei? Laufzeit oder Deployment? Diese Fragen sind wichtig, aber sie greifen zu kurz.

Zwei typische Projektsituationen verdeutlichen wiederkehrende Grenzen:

• In Szenario A basiert die Konfiguration auf einem datenbankgesteuerten Modell, ähnlich wie bei SAP. Änderungen am Datenmodell führen unweigerlich zu Anpassungen am Code, an den Tests und auch an den Geschäftsprozessen.
• In Szenario B liegen die Konfigurationen in JSON-Dateien, die von Workflows interpretiert wurden. In diesem Fall beschränkt sich die Wiederverwendbarkeit auf Implementierungen in ähnlichen Workflows. Anpassungen sind häufig nur vor oder nach Aktivitäten oder Aufgaben möglich.

Beide Ansätze funktionieren, zeigen jedoch typische Grenzen. Die zentrale Erkenntnis: Konfiguration ist keine isolierte technische Entscheidung, sondern Teil der Architektur.

Konfiguration als architektonische Entscheidung

Konfigurierbare Systeme lassen sich entlang drei grundlegender Aspekte strukturieren: Was variiert, wer ist für die Variation verantwortlich und welche Folgen hat eine fehlerhafte Konfiguration? Diese drei Fragen bestimmen die Art der Konfiguration, das Governance-Modell und die Testarchitektur, bevor die erste Implementierungsentscheidung getroffen werden kann. 

Im Projektalltag umfasst der Begriff "Konfiguration" viele Konzepte: Umgebungsvariablen, Feature Flags, Datenbanktabellen, JSON- oder YAML-Dateien und Regelwerke. Diese Unterschiede beeinflussen, wer für die Konfiguration verantwortlich ist, wann sie in Kraft tritt, wie sie getestet werden kann und welchen Governance-Aufwand sie erfordert.

Bindungszeitpunkt als Leitkonzept

Alle Konfigurationstypen verbindet ein zentrales Konzept: der Bindungszeitpunkt. In diesem Moment wird eine Konfiguration wirksam, entweder zur Compile-Zeit, beim Deployment oder zur Laufzeit. Je früher die Bindung erfolgt, desto stabiler ist das System, allerdings ist es dann auch weniger flexibel. Je später die Bindung erfolgt, desto flexibler ist das System, allerdings fallen die Risiken höher aus. Dementsprechend höher ist auch der Bedarf an Governance, also an Validierung, Nachvollziehbarkeit, Auditierung und Rollback-Fähigkeit.

Konfiguration testen: das Problem der späten Bindung

Wenn die Systemlogik nicht im Code steht, sondern als JSON-Payload zur Laufzeit geladen wird, stellt sich eine konkrete Frage: Wie testet man ein System, dessen Verhalten durch Konfiguration bestimmt wird? Klassische Unit-Tests prüfen die Implementierung, aber nicht, ob eine Konfiguration im gesamten Werteraum korrekt funktioniert. Fachliche Invarianten müssen daher als testbare Properties formuliert werden.

Domain-Driven Design in konfigurierbaren Systemen

Die Soft-Coding-Falle

Wichtige Dimensionen konfigurierbarer Systeme

Fünf Dimensionen bestimmen die langfristige Tragfähigkeit.

Dimension	Kernfrage
Fachliche Modellierung	Spiegelt die Konfiguration die Sprache des Geschäfts wider?
Datenmodellierung	Wie stabil ist das Schema? Wie teuer sind Änderungen?
Prozessdesign	Wie entstehen und durchlaufen Änderungen den Prozess?
Architektur	Wo wird Konfiguration interpretiert?
Governance	Wie werden Versionierung, Audit und Zugriff gesteuert?

Zwei Referenzszenarien

Nachfolgend werden zwei typische Projektsituationen unter die Lupe genommen.

Szenario A – datenbankgetrieben: ein Multi-Country-System mit Partnerkategorien, Provisionsmodellen und regulatorischen Anforderungen.
Szenario B – schemagetrieben: ein Produktsystem mit mehreren Produktlinien auf gemeinsamer Codebasis.

Konfigurationsqualität entsteht nicht durch Tools, sondern durch klare Architekturentscheidungen.

Taxonomie: acht Konfigurationstypen

Die Taxonomie ist kein Technologiekatalog, sondern ein Entscheidungsinstrument. Jeder Konfigurationstyp steht für eine Kombination aus Bindungszeitpunkt, Verantwortlichkeit, Semantik und Governance-Aufwand.

Typ	Eigentümer	Bindungszeitpunkt	Gov.-Aufwand	Beispiele
T1 – Parametrisierung	Ops / Dev	Build / Load	niedrig	Env Vars, Vault
T2 – Feature Flags	Dev / Ops	Laufzeit	mittel	LaunchDarkly, Unleash
T3 – Convention over Config	Dev	Build	sehr niedrig	Spring Boot, Rails
T4 – DB-gesteuert	Business / Analyst	Laufzeit	hoch	SAP SPRO, EAV
T5 – schemagetrieben	Product / Dev	Laufzeit	mittelhoch	JSON Schema, Avro
T6 – Regelmaschinen	Business / Ops	Laufzeit	hoch	Camunda DMN, OPA
T7 – Software Product Lines	Architekt	Compile / Build	sehr hoch	FeatureIDE
T8 – Config as Code / GitOps	Dev / Ops	Deployment	mittel	Terraform, Helm

T1 – Parametrisierung

Werte aus dem Code werden externalisiert und beim Start geladen. Begrenzte Ausdruckskraft, ungeeignet für fachliche Logik.

Architektonische Einordnung: frühe Bindung, niedriger Governance-Aufwand, keine fachliche Semantik.

T2 – Feature Flags

Dynamische Steuerung von Verhalten zur Laufzeit, Risiko von "Toggle Debt" und Intransparenz.

Architektonische Einordnung: späte Bindung. Um Service-Aufrufe partnertypabhängig zu steuern, werden Feature Flags genutzt. Der Prozess-Workflow bleibt identisch, aber je nach Partnertyp wird ein anderer Service aufgerufen. Das funktioniert gut, solange die Flags dokumentiert sind und einen klaren Eigentümer haben. Ansonsten entsteht Toggle Debt: Flags, die niemand mehr zu entfernen wagt, weil unklar ist, welche Partner sie noch benötigen. Der Knight-Capital-Verlust von 460 Mio. Dollar (2012) illustriert das Extremszenario.

T3 – Convention over Configuration

Konventionen ersetzen explizite Konfiguration. Risiken: implizites Verhalten, schwer erkennbare Abweichungen.

Architektonische Einordnung: frühe Bindung, minimale Governance, geeignet für technische Variabilität.

T4 – Datenbankgesteuerte Konfiguration

Systemverhalten über Datenmodelle zur Laufzeit gesteuert. Risiken: starke Kopplung zwischen Code und Datenmodell, implizite Semantik, Soft Coding.

Architektonische Einordnung: späte Bindung, hohe Governance-Anforderungen. Das typische Symptom ist, dass eine Schema-Änderung eine Code-Änderung erzwingt, die wiederum eine Test-Änderung nach sich zieht. Plötzlich erfordert dann ein vermeintliches Konfigurations-Update einen vollständigen Release-Zyklus.

T5 – Schemagetriebene Konfiguration

Strukturierte Dokumente mit Validierung; Risiko von Konfigurationsdrift und begrenzter Prozessausdruckskraft.

Architektonische Einordnung: späte Bindung mit strukturierter Validierung. Entscheidend in der Praxis: Das Schema ist nicht nur ein technisches Validierungsartefakt, sondern die Dokumentation der Konfigurationsstruktur. Gut beschriebene Felder mit klaren Bezeichnungen und Beispielwerten ermöglichen schnelle, sichere Änderungen auch durch Nicht-Entwickler.

T6 – Regelmaschinen

Fachliche Entscheidungen in Regeln ausgelagert, zur Laufzeit ausgewertet. Risiken: Debugging und Testbarkeit sind komplex.

Architektonische Einordnung: späte Bindung mit hoher Ausdruckskraft; Semantik liegt in der Entscheidungslogik. Camunda-Regeln sowie der aufgerufene Code müssen sorgfältig dokumentiert werden: Feldbeschreibungen, Regelbegründungen und konkrete Beispiele sind Voraussetzung dafür, dass neue Teammitglieder diese Regeln korrekt implementieren können.

T7 – Software Product Lines

Variabilität als Architekturmodell, zur Build-Zeit entschieden. Risiken: hoher initialer Aufwand, geringe Laufzeitflexibilität.

Architektonische Einordnung: frühe Bindung mit maximaler Kontrolle. Ein typisches Beispiel hierfür ist Szenario B: Ein Produktsystem für mehrere Produktlinien in mehreren Märkten beschreibt strukturell eine Software Product Line. Das Variabilitätsmodell wurde implizit durch T5 abgebildet – ein Clone-and-Own-Problem, das nie als solches erkannt wurde.

T8 – Configuration as Code / GitOps

Konfiguration als versionierter Code, über Deployment gesteuert. Risiken: begrenzte fachliche Ausdruckskraft, Verzögerung durch Deployment-Zyklen.

Architektonische Einordnung: Deployment-Bindung mit starker Governance – das Modell, an dem alle anderen Typen gemessen werden sollten.

Die Wahl des Konfigurationstyps bestimmt, wo Semantik liegt, wer Verantwortung trägt und wie Risiko verteilt wird.

T4 – Datenbankgesteuerte Konfiguration

Das SAP-SPRO-Customizing-Framework ist die kanonische Enterprise-Implementierung: ein strenges Schichtenmodell, das das Customizing von Entwicklungsobjekten trennt. Szenario A zeigt, was passiert, wenn lediglich "Konfiguration via Tabellen" ohne den umgebenden Rahmen übernommen wird.

Domain-Driven Design – die richtige Sequenz

Ein häufiger Fehler ist die Sequenzierungsentscheidung: Zuerst wird das Datenmodell entworfen und danach das Domänenmodell abgeleitet. Was stattdessen gebraucht wird:

• zuerst: externe Domänenmodelle analysieren, die das eigene System beeinflussen
• dann: Die Ubiquitous Language des eigenen Systems definieren – was bleibt isoliert, was wird geteilt? 
• erst dann: das Datenmodell entwerfen, das die Domänenkonzepte abbildet 
• parallel: Governance und Entwicklungsprozess für Multi-Country-Rollout definieren

In Szenario A wurden die Datenbanktabellen zuerst entworfen, die Konfigurationslogik im Schema abgebildet und der Anwendungscode danach um dieses Schema entwickelt. Ein Domänenmodell existierte nicht. Nach Erkennen dieses Umstands wurde die richtige Sequenz eingeführt.

Das eigentliche Problem sind importierte Bounded Contexts. Dabei integriert ein System Konzepte aus umliegenden Systemen, ohne eigene Domänenmodelle zu verwenden. Bezeichner, Strukturen und implizite Annahmen werden übernommen und direkt in Konfigurationstabellen eingebaut. Sobald sich ein externes Konzept ändert, ändert sich auch das Schema.

Die Lösung ist der Anti-Corruption Layer (ACL) im DDD. Er übersetzt zwischen der Sprache eines externen Systems und der eigenen Ubiquitous Language und schützt so den eigenen Bounded Context.

Lösung: Anti-Corruption Layer an der Systemgrenze

// Ohne ACL: externer Bezeichner direkt in der Domaene
CommissionRate rate = configRepository.findByPartnerCode("PTNR_TYPE_02");
 
// Mit ACL: Uebersetzung an der Systemgrenze
@Component
public class PartnerSystemAcl {
  public PartnerType translate(String externalPartnerCode) {
	return switch (externalPartnerCode) {
  	case "PTNR_TYPE_01" -> PartnerType.INDEPENDENT_BROKER;
  	case "PTNR_TYPE_02" -> PartnerType.BANCASSURANCE;
  	default -> throw new UnknownPartnerCodeException(externalPartnerCode);
	};
  }
}
CommissionRate rate = configRepository.findByPartnerType(
  partnerSystemAcl.translate(externalCode)
);

Anti-Pattern: Shadow Logic – Entscheidungslogik in JSON ausgelagert

// Anti-Pattern: Entscheidungslogik im JSON-Feld
{
  "commission_modifiers": [
	{ "if": "regulatory_flag == true", "apply": "surcharge_v3", "priority": 1 },
	{ "if": "amount > 15000 && market == \"DE\"", "apply": "tier_b_rate", "priority": 2 }
  ]
}
 
// Der Interpreter – nicht typsicher, nicht testbar:
private boolean evaluate(String condition, CommissionContext ctx) {
  return expressionParser.parse(condition).evaluate(ctx);
  // Tippfehler wie "regulatory_flaag" werden erst zur Laufzeit entdeckt.
}

Lösung: JSON als reiner Parameter-Träger, Logik in Camunda DMN

// Loesung: JSON enthaelt nur stabile Parameter
{
  "product_type": "term-life",
  "market": "DE",
  "commission_model": "tiered",
  "tiers": [
	{ "threshold": 0, 	"rate": 0.02 },
	{ "threshold": 15000, "rate": 0.03 }
  ]
}
// Die Entscheidungslogik liegt in einer DMN-Tabelle in Camunda –
// typsicher, testbar, dokumentierbar.

Event Storming macht Domänenereignisse sichtbar und hilft, Bounded Contexts zu identifizieren, bevor externe Konzepte unbewusst übernommen werden. Es empfiehlt sich beispielsweise, dass diese im Context Mapping visualisiert werden. Das offenbart: Erst wenn diese Grenzen klar sind, wird sichtbar, was variieren darf:

Fachliches Konzept	Variationspunkt?	Konfigurationstyp
Provisionsmodell	Ja – pro Partnertyp und Markt	T4 – datenbankgesteuert
Produktstruktur	Ja – pro Produktlinie	T5 – schemagetrieben
Marktfreigabe	Ja – pro Regulierung	T6 – DMN-Regel
Berechnungslogik	Nein – stabil im Code	kein Konfigurationstyp

Datenmodellierung

EAV-Muster erzeugen Performance-Probleme, gebrochene referentielle Integrität und schwer lesbare Abfragen. Schema-Änderungen sind Breaking Changes. Ein bewährter Ansatz ist es deshalb, von Anfang an auf Liquibase zu setzen: Jede Änderung am Konfigurationsschema wird als versioniertes Changeset dokumentiert.

Schema-Versionierung mit Liquibase

<!-- db/changelog/001-initial-commission-config.xml -->
<changeSet id="001" author="team">
  <createTable tableName="commission_config">
	<column name="id"       	type="BIGINT" autoIncrement="true"><constraints primaryKey="true"/></column>
	<column name="partner_type" type="VARCHAR(50)"><constraints nullable="false"/></column>
	<column name="market"       type="VARCHAR(2)"><constraints nullable="false"/></column>
	<column name="rate"         type="DECIMAL(5,4)"><constraints nullable="false"/></column>
  </createTable>
</changeSet>
 
<changeSet id="002" author="team">
  <addColumn tableName="commission_config">
	<column name="valid_from" type="DATE"><constraints nullable="false"/></column>
	<column name="valid_until" type="DATE"/>
  </addColumn>
</changeSet>

Prozessdesign

Ein funktionierender Konfigurationsprozess definiert klar, wer Konfigurationsänderungen beantragen, prüfen und freigeben darf. Zudem müssen Audit-Trails und Rollback-Mechanismen vorhanden sein.

Was häufig fehlt, ist nicht die technische, sondern die fachliche Governance: Ohne explizites Domänenmodell lässt sich kaum beurteilen, ob eine Änderung fachlich korrekt ist, selbst wenn sie technisch korrekt durchgeführt wurde.

Die architektonische Lösung: der Konfigurationsservice

Die Lösung ist ein Konfigurationsservice, der die Tabellen besitzt und nach außen eine stabile, versionierte API exponiert.

Listing 1 – T4: Direkter Tabellenzugriff vs. Konfigurationsservice

// PROBLEM: Anwendungscode greift direkt auf Tabellen zu
BigDecimal rate = jdbcTemplate.queryForObject(
  "SELECT rate FROM partner_config WHERE type = ? AND country = ?",
  BigDecimal.class, partnerType.name(), country.getAlpha2()
);
 
// LOESUNG: Konfigurationsservice als stabiler Vertrag
@Service
public class CommissionConfigService {
  public CommissionRate getCommissionRate(PartnerType partner, CountryCode country) {
	CommissionRateEntity entity = repository
  	.findByPartnerAndCountry(partner, country)
  	.orElseThrow(() -> new ConfigurationNotFoundException(partner, country));
	return new CommissionRate(entity.getRate(), entity.getCurrency());
  }
}
// Tests mocken den Service – nicht die Tabelle.

T4 und T5 schließen sich nicht gegenseitig aus: T1 steuert Infrastrukturparameter, T2 kontrolliert Feature-Rollouts, T4 verwaltet fachliche Parameter und T5 beschreibt Produktstrukturen. Die Grenzen zwischen den Typen müssen explizit gezogen und maschinell geprüft werden.

CI/CD-Gate: Konsistenzvalidierung zwischen T4 und T5

@Component
public class ConfigConsistencyValidator {
  public void validate() {
	List<CoverageOption> allOptions = t5Repository.findAllCoverageOptions();
	List<String> missing = allOptions.stream()
  	.filter(option -> !t4Repository.existsForAllMarketsAndPartners(option))
  	.map(CoverageOption::getId).toList();
	if (!missing.isEmpty()) {
  	throw new ConfigurationInconsistencyException(
    	"Coverage Options ohne Provisionssatz: " + missing);
	}
  }
}

T5 – Schemagetriebene Konfiguration

Die schemabasierte Konfiguration legt das Systemverhalten bei strukturierten Dokumenten fest, deren Gültigkeit durch ein Schema definiert ist. In Szenario B wurde T5 für die Produktdefinitionen zusammen mit den Infrastrukturparametern (T1) und den Feature Flags (T2) verwendet.

Das Produktmodell wurde für einen Markt konzipiert und kann durch Schema-Änderungen angepasst werden. Was fehlte, war die Möglichkeit, den Workflow strukturell zu konfigurieren: Als ein neuer Markt unterstützt werden sollte, nutzte das neue System nur etwa 60 % des ursprünglichen – weil die Unterschiede in Prozessen und Services tiefer gingen, als die Extension Points abdecken konnten.

Domain-Driven Design

Schema-Felder müssen in der Ubiquitous Language der Domäne benannt werden. In Szenario B war das JSON-Schema konzeptuell sauber, trug aber das Gewicht eines Domänenmodells, das der Zielmarkt nur teilweise benötigte.

Eine explizite Analyse der Ubiquitous Language beider Märkte hätte die strukturellen Inkompatibilitäten sichtbar gemacht, bevor die Implementierung begann.

Beispiel 2 zeigt das Schema-Problem direkt: interne Codes statt Domänensprache.

Anti-Pattern: interne Codes

// Anti-Pattern: interne Bezeichner
{ "prod_type_cd": "03", "calc_meth": "AB", "cov_opts": [{ "opt_id": "C2", "riders": ["R_AD"] }] }

Lösung: Domänensprache

// Loesung: Domaenensprache
{ "product_type": "term-life", "premium_model": "age-band-table",
  "coverage_options": [{ "id": "extended", "riders": ["accidental-death"] }] }

Datenmodellierung

In regulierten Branchen stellt Konfigurationsdrift – unterschiedliche Schema-Versionen in Entwicklung, Staging und Produktion – ein Compliance-Risiko dar. Schema-Versionierung und automatische Paritätsprüfungen sind daher obligatorisch.

Prozessdesign

Der Adaptionsprozess für den neuen Markt wurde nie entworfen, bevor die Architektur fixiert war. Welche Prozessschritte sind identisch, welche konfigurierbar und welche strukturell verschieden? Diese Fragen sind Architekturvoraussetzungen und keine Business-Analyse.

Schema-Validierung als Gate

In Szenario B wurden fehlerhafte JSON-Dateien erst zur Laufzeit entdeckt. Die Lösung ist eine automatische Schema-Validierung als hartes CI/CD-Gate.

Listing 2 – T5: Schema-Validierung als Gate

// Problem: schema-valide, aber fachlich falsch
{ "premium_model": "age-band-tabel", "markets": "DE" }
 
// Loesung: JSON Schema + CI/CD-Gate
{ "properties": {
	"premium_model": { "type": "string", "enum": ["age-band-table","risk-score","flat-rate"] },
	"markets": { "type": "array", "items": { "type": "string" } }
  }
}
// Fehler wird im CI/CD abgefangen – kein Deployment, kein Produktionsausfall.

Die Sequenz, die entscheidet

Der häufigste Fehler ist nicht, die falsche Technologie zu wählen, sondern sie zu früh zu wählen. In den meisten Projekten beginnt die Diskussion bei Schritt 5: Welches Tool, welche Datenbank, welches Schema-Format? Das fühlt sich produktiv an. Dabei bleibt die eigentlich entscheidende Frage unbeantwortet: Was soll variieren – und für wen, in welchem Rhythmus und mit welcher Konsequenz bei einem Fehler? Ohne diese Antwort wird eine Technologiewahl ohne Karte getroffen.

Konfigurationsdesign ist der letzte, nicht der erste Schritt.

Schritt 1 – Domänenmodell: Bounded Contexts, Aggregate, Ubiquitous Language (DDD).

Schritt 2 – Prozessmodell: Geschäftsprozesse kartieren und Variationspunkte identifizieren.

Schritt 3 – Konfigurationsdomänen: Variationspunkte klassifizieren, Eigentümer und Governance-Modell zuweisen.

Schritt 4 – Konfigurationsvertrag: Die stabile API definieren, die Konfigurationsdomäne und Anwendungscode trennt.

Schritt 5 – Typwahl: Jetzt – und erst jetzt – den Implementierungsmechanismus pro Domäne wählen!

Schritt 6 – Validierungsinfrastruktur: Schema-Validierung, property-based Tests, Umgebungsparitätsprüfungen.

Ubiquitous Language muss vor Schritt 3 stehen, denn ohne sie lautet die Antwort auf "Was variiert?" unweigerlich: Tabellen, Felder, Flags – technische Artefakte, keine Domänenkonzepte.

Governance als gemeinsamer Nenner

Auf den ersten Blick unterscheiden sich die beiden Szenarien deutlich voneinander, auch in Bezug auf ihre Governance-Reife.

In Szenario A gab es eine klare Governance-Struktur: Verantwortlichkeiten waren definiert, Änderungen nachvollziehbar und Rollbacks möglich. Die Herausforderung lag nicht in der Governance selbst, sondern im fehlenden Domänenmodell. Ohne dieses Modell ließ sich kaum beurteilen, ob eine Konfigurationsentscheidung inhaltlich richtig war.

In Szenario B zeigte sich eine andere Schwäche: Die Konfiguration war nicht eindeutig versioniert, Unterschiede zwischen den Umgebungen waren schwer erkennbar und das Verhalten war nicht reproduzierbar.

Beide Fälle zeigen: Governance allein reicht nicht, sie braucht ein Domänenmodell als Grundlage. Ein solches allein reicht ebenfalls nicht aus – es braucht Governance als Schutzschicht.

Fünf Governance-Dimensionen

• Versionierung: Welche Konfiguration ist aktiv?
• Nachvollziehbarkeit: Wer hat was wann geändert?
• Validierung: Ist die Konfiguration korrekt und vollständig?
• Reproduzierbarkeit: Führt dieselbe Konfiguration zum selben Verhalten?
• Zugriffssteuerung: Wer darf Änderungen vornehmen?

Governance muss Teil der Architektur sein und keine nachträgliche Ergänzung:

Semantik → Variabilität → Architektur → Konfiguration → Governance.

Property-Based Testing für konfigurierbare Systeme

Je mehr konfiguriert wird, desto mehr Systemlogik verschiebt sich aus dem Code in Konfigurationsartefakte. Klassische Tests stoßen hier an Grenzen: Sie prüfen einzelne Fälle anstelle des gesamten Konfigurationsraums.

Das Problem ist kein einzelner Fehler, sondern der Konfigurationsraum.

Vom Beispiel zur Invarianten

In der vorliegenden JSON-Konfigurationsdatei besteht die Schema-Validierung problemlos, ist aber fachlich falsch:

product-config.json – schema-valide, aber fachlich falsch

{ "commission_model": "tiered",
  "tiers": [
	{ "threshold": 0, 	"rate": 0.05 },
	{ "threshold": 15000, "rate": 0.02 }
  ]
}
// Struktur korrekt – aber Provision sinkt bei hoeherem Betrag. Fachlich falsch.

Mit jqwik wird die fachliche Invariante als automatisch geprüfter Property-Test formuliert:

 

property-based Test mit jqwik (Java)

@Property
void higherAmountYieldsHigherOrEqualCommission(
  @ForAll @DoubleRange(min = 0,      max = 14_999)	double amountLow,
  @ForAll @DoubleRange(min = 15_000, max = 1_000_000) double amountHigh
) {
  CommissionRate rateLow  = commissionService.calculate(config, amountLow);
  CommissionRate rateHigh = commissionService.calculate(config, amountHigh);
  assertThat(rateHigh.value()).isGreaterThanOrEqualTo(rateLow.value());
}
// jqwik findet den Fehler sofort: rate=0.02 < rate=0.05 verletzt Monotonie.

Drei Klassen von Invarianten

Invariante	Beispiel	Was sie schützt
Wertebereich	rate >= 0 für alle Eingaben	negative Provisionen
Monotonie	höherer Betrag → gleiche oder höhere Rate	Fehlanreize im Vergütungsmodell
Vollständigkeit	Jeder gültige Markt hat eine Tier-Stufe.	Laufzeitfehler bei unbekanntem Markt

3-Schichten-Teststrategie

• Die Schema-Validierung prüft Struktur und Typen.
• Unit-Tests prüfen die Implementierung.
• Property-based Tests prüfen fachliche Invarianten im gesamten Konfigurationsraum.

Je später die Bindung, desto größer der Konfigurationsraum – und desto wichtiger werden generative Tests.

Entscheidungsrahmen

Die folgenden Fragen klingen einfach, werden in der Praxis jedoch selten gestellt – meistens, weil die Antwort unbequem ist:

• Wer ändert diese Konfiguration? → bestimmt Eigentümer und Governance-Rigor
• Wie häufig ändert sie sich? → bestimmt Bindungszeitpunkt und Änderungsprozess
• Was kostet eine Fehlkonfiguration? → bestimmt Validierungs- und Rollback-Anforderungen
• Was ist der Variationsumfang? → bestimmt den passenden Konfigurationstyp
• Sind Variationspunkte in der Ubiquitous Language beschrieben? Technische Bezeichnungen signalisieren eine unvollständige Modellierung.
• Wird Logik ausgelagert (Soft Coding)? Wenn ja: Ist sie noch testbar und für Fachbereiche lesbar?
• Können fachliche Invarianten als testbare Properties formuliert werden? Wenn nicht, fehlt entweder das Domänenmodell oder die Testarchitektur.
• Ist der Governance-Lebenszyklus definiert? Wer ändert, prüft, auditiert und was ist das Rollback-Verfahren?

ADRs: 

Konfigurationstyp-Entscheidungen sind als Architecture Decision Records zu dokumentieren: Warum diese Wahl? Welche Alternativen gibt es? Welche Trade-offs bestehen?

Rollenspezifische Leitlinien

Rolle	Leitlinie
CTO / Engineering Lead	Konfigurationssprawl und fehlende Governance sind eine technische Schuld – messen, Eigentümer zuweisen, abbauen!
Architekt	Domänenmodell zuerst! Konfigurationsvertrag als explizites Artefakt. Governance-Lebenszyklus von Anfang an mitdenken!
Principal Engineer	Schema-Validierung, property-based Tests und Umgebungsparität sicherstellen! Soft Coding erkennen und benennen!
Domain Expert / BA	Ubiquitous Language einfordern! Fachliche Invarianten als Basis für PBT und Governance-Regeln formulieren!

Fazit

Diese Muster zeichnen sich in Projekten immer wieder ab. Ein System wird konfigurierbar gemacht, doch niemand hat vorab definiert, was Variabilität in diesem Kontext bedeutet und welche Elemente stabil bleiben müssen.

In Systemen ähnlich Szenario A wird das Datenmodell entworfen, bevor das Domänenmodell klar ist. Externe Systeme bringen ihre Konzepte und Bezeichner mit und werden unreflektiert übernommen. Stattdessen sollten zuerst die externen Domänenmodelle analysiert und die Ubiquitous Language des eigenen Systems definiert, dann das Datenmodell entworfen und die Governance für den Multi-Country-Rollout von Anfang an als Architekturentscheidung behandelt werden.

In Systemen ähnlich Szenario B ist die Architektur mit Workflows, Erweiterungspunkten und JSON-Konfiguration bereits gesetzt. Wenn der nächste Markt strukturell anders ist als angenommen, reichen die Extension Points nicht. Was dann fehlt, ist eine Analyse, die vor der Implementierung hätte stattfinden müssen: Wie ähnlich ist der Zielmarkt dem Referenzmodell wirklich? Was variiert? Was nicht?

Konfiguration ohne Governance ist ein Risiko und Variabilität ohne Domänenmodell ist eine Annahme, die sich irgendwann als falsch herausstellt.

Autor