Fitness Functions und evolutionäre Architektur

Von der einmaligen Bewertung zur kontinuierlichen Prüfung

Eine Bewertung wie die ATAM (Abschnitt 11.1) ist eine Momentaufnahme. Am Tag nach ihrem Ende beginnen Entwickler, das System zu ändern, und jede Änderung kann still eine Entscheidung rückgängig machen, auf die sich die Bewertung gestützt hat: ein bequemer Import über eine Modulgrenze hinweg, ein zusätzlicher synchroner Aufruf auf dem Bestellpfad, eine Bibliothek mit einer bekannten Schwachstelle. Abschnitt 1.7 hat das Ergebnis beschrieben: Erosion, wenn die Architektur verletzt wird, und Drift, wenn sie ignoriert wird. Regelmäßige Reviews fangen einiges davon ab, Monate zu spät. Die Idee dieses Abschnitts ist, die wichtigsten Architekturentscheidungen automatisch und kontinuierlich zu prüfen, so wie Unit-Tests das Verhalten prüfen.

Der Begriff stammt aus Building Evolutionary Architectures (O’Reilly, 2017) von Neal Ford, Rebecca Parsons und Patrick Kua, dessen zweite Ausgabe, mit Pramod Sadalage, im November 2022 erschien. Sie haben ihn aus der evolutionären Informatik entlehnt, wo eine Fitness Function bewertet, wie nah eine Kandidatenlösung am Ziel ist, damit der Algorithmus die besseren Varianten behalten kann. In der Architektur ist das Ziel die Menge der Merkmale, die das System behalten muss, während sich alles andere ändert.

Was eine Fitness Function ist

Die zweite Ausgabe definiert eine architektonische Fitness Function als jeden Mechanismus, der eine objektive Integritätsbewertung eines oder mehrerer Architekturmerkmale liefert. Drei Wörter in dieser Definition tragen die Last. Jeder Mechanismus: Ein Unit-Test, eine Regel der statischen Analyse, ein Lasttest, ein Monitor, ein Chaos-Experiment oder sogar ein geplantes manuelles Review kommen alle infrage. Objektiv: Das Ergebnis darf nicht davon abhängen, wer die Prüfung ausführt; „der Code fühlt sich gut strukturiert an“ ist keine Fitness Function, „kein Paket in der Domänenschicht importiert das Web-Framework“ schon. Architekturmerkmal: Die Prüfung schützt eine Qualität, für die die Architektur da ist (Performance, Verfügbarkeit, Änderbarkeit, Sicherheit, Datenkompatibilität), keine Geschäftsregel; das ist die Aufgabe gewöhnlicher Tests.

In der Praxis hat eine nützliche Fitness Function noch einige weitere Eigenschaften. Sie ist auf eine Anforderung rückführbar, idealerweise auf ein Qualitätsszenario, dessen Antwortmaß zu ihrem Schwellenwert wird (Abschnitt 2.3). Sie hat einen Verantwortlichen, der entscheidet, was bei einem Fehlschlag passiert. Sie schlägt laut fehl, indem sie einen Build abbricht oder jemanden alarmiert, statt ein Dashboard zu füllen, das niemand liest. Und ihr Schwellenwert samt Begründung ist dokumentiert, meist in einem ADR, damit ein späteres Team eine Regel, die etwas Wichtiges schützt, von einer willkürlichen Zahl unterscheiden kann.

Abschnitt 3.8 hat die wichtige Abgrenzung zu Metriken gezogen: Eine Metrik beschreibt, eine Fitness Function entscheidet. Eine Kopplungsmetrik auf einem Dashboard zeigt Ihnen, dass es schlechter wird; eine Fitness Function kodiert eine Entscheidung, die das Team bereits getroffen hat, sodass ihr Bruch eine bewusste Wahl erzwingt: den Code korrigieren oder die Regel ändern und festhalten, warum.

Kategorien von Fitness Functions

Ford und seine Mitautoren ordnen Fitness Functions entlang mehrerer unabhängiger Dimensionen ein. Die Einteilung ist weniger als Taxonomie nützlich denn als Denkanstoß beim Entwurf: Die Frage „Sollte das atomar oder holistisch, ausgelöst oder kontinuierlich sein?“ führt oft zu einer besseren Prüfung als der, die einem zuerst eingefallen ist.

Holistische Prüfungen verdienen Aufmerksamkeit, weil Qualitäten zusammenwirken: Sicherheitsmaßnahmen kosten Latenz, Caching erschwert die Aktualität der Daten, und ein atomarer Test jeder einzelnen kann bestehen, während die Kombination scheitert. Kontinuierliche Prüfungen sind wichtig, weil manche Merkmale nur in Produktion existieren: echte Nutzerlatenz, echte Ausfallarten, echte Kosten. Ein gesundes Portfolio kombiniert schnelle, atomare, ausgelöste Prüfungen im Build mit einer kleineren Zahl langsamerer holistischer Prüfungen vor dem Release und kontinuierlichen Prüfungen in Produktion.

Fitness Functions über die Qualitäten hinweg

Die meisten Teams beginnen mit der Struktur, weil Strukturprüfungen günstig, schnell und deterministisch sind, und ergänzen dann Prüfungen für Performance, Sicherheit, Resilienz und Daten, während die Pipeline reift. Die Tabelle nennt typische Beispiele; Werkzeuge ändern sich, die Muster nicht.

Evolutionäre Architektur und inkrementelle Änderung

Fitness Functions sind die eine Hälfte dessen, was Ford, Parsons, Kua und Sadalage evolutionäre Architektur nennen: eine Architektur, die gelenkte, inkrementelle Änderung über mehrere Dimensionen unterstützt. Jeder Teil dieser Formulierung ist eine Entwurfsanforderung.

Inkrementelle Änderung hat eine Entwicklungs- und eine Betriebsseite. Entwickler müssen kleine Änderungen sicher vornehmen können; das hängt von Modularität und angemessener Kopplung ab (Kapitel 3) und davon, jeden unabhängig deploybaren Teil, das Architekturquantum aus Abschnitt 5.1, klein genug zu halten, um ihn ohne Abstimmung mit anderen zu ändern. Der Betrieb muss kleine Änderungen häufig und sicher ausliefern können; das hängt von einer Deployment-Pipeline, schrittweisem Rollout und schnellem Rollback ab (Abschnitt 10.5). Gelenkt ist der Punkt, an dem Fitness Functions ins Spiel kommen: Sie definieren, was „fit“ bedeutet, und verhindern, dass Inkremente es verschlechtern. Mehrere Dimensionen erinnert daran, dass Architektur nicht nur Codestruktur ist: Daten, Sicherheit, Betrieb, Teamstruktur und Kosten entwickeln sich alle weiter und müssen alle geschützt werden.

Der Ansatz verändert, wie Architekten über die Zukunft denken. Statt jede Anforderung vorherzusagen und im Voraus Flexibilität dafür einzubauen, was, wie Abschnitt 3.8 gezeigt hat, teuer und oft falsch ist, hält das Team das System leicht änderbar und schützt nur die Merkmale, die zählen, während es andere Entscheidungen auf den Last Responsible Moment verschiebt (Abschnitt 1.6). Kritiker weisen auf echte Grenzen hin. Nicht jede Qualität lässt sich automatisch oder günstig prüfen; schlecht gewählte Schwellenwerte erzeugen Rauschen, das Teams zu ignorieren lernen; und manche Entscheidungen, etwa für eine Datenbank oder einen Cloud-Anbieter, bleiben Einwegtüren, wie gut die Pipeline auch ist. Evolutionäre Architektur ist eine Disziplin, die umkehrbaren Teile umkehrbar und die wichtigen Teile geschützt zu halten, kein Versprechen, dass sich später alles ändern lässt.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    friday_peak: { executor: 'constant-arrival-rate', rate: 100, timeUnit: '1s',
                   duration: '10m', preAllocatedVUs: 300 },   // 100 orders per second
  },
  thresholds: {   // the scenario's response measure, as pass/fail rules
    'http_req_duration{name:place_order}': ['p(95)<1500', 'p(99)<3000'],
    'http_req_failed{name:place_order}': ['rate<0.001'],
  },
};

const order = { restaurantId: 'r-42', items: [{ sku: 'pad-thai', qty: 1 }] };

export default function () {
  const res = http.post(`${__ENV.BASE_URL}/orders`, JSON.stringify(order), {
    headers: { 'Content-Type': 'application/json' }, tags: { name: 'place_order' } });
  check(res, { 'order accepted': (r) => r.status === 201 || r.status === 202 });
}

# Fitness function: checkout keeps accepting orders when payments hang (illustrative)
# Runs weekly in staging; toxiproxy, api and ledger are test fixtures.
def test_orders_survive_payment_provider_outage(toxiproxy, api, ledger):
    toxiproxy.add_latency("payment-provider", latency_ms=30_000)   # provider hangs
    placed = [api.place_order(sample_order()) for _ in range(200)]

    assert all(r.status in (201, 202) for r in placed)            # still accepted
    assert all(r.json()["state"] == "PENDING_PAYMENT" for r in placed)
    assert max(r.elapsed_seconds for r in placed) < 10            # told within 10 s

    toxiproxy.remove_toxics("payment-provider")                    # provider recovers
    ledger.wait_until_settled(timeout_seconds=300)
    assert ledger.lost_orders(placed) == []                        # none lost

# .importlinter: only the POS adapters may use vendor SDKs
[importlinter]
root_package = fooddelivery
include_external_packages = True

[importlinter:contract:pos-vendors-isolated]
name = Vendor POS SDKs are used only inside the POS adapters
type = forbidden
source_modules =
    fooddelivery.restaurant.domain
    fooddelivery.restaurant.api
    fooddelivery.ordering
forbidden_modules =
    tillpro_sdk
    kitchenlink

[importlinter:contract:adapters-independent]
name = POS adapters do not import each other
type = independence
modules =
    fooddelivery.restaurant.pos_adapters.tillpro
    fooddelivery.restaurant.pos_adapters.kitchenlink

Die Datenkompatibilität wird auf dieselbe Weise geschützt. Bevor eine Änderung am Event OrderPlaced gemergt werden kann, fragt die Pipeline die Schema Registry, ob das neue Schema nach der Kompatibilitätsregel des Subjects mit der zuletzt registrierten Version kompatibel ist, und schlägt fehl, wenn nicht:

# Data fitness function: block the merge if the new event schema would break consumers
curl -s -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  --data @build/order-placed-v7.request.json \
  "$SCHEMA_REGISTRY_URL/compatibility/subjects/order-placed-value/versions/latest" \
  | jq -e '.is_compatible == true'

Fitness Functions entwerfen, die Bestand haben

Beginnen Sie klein und mit dem Wichtigen. Wählen Sie die drei bis fünf Merkmale, die der Utility Tree am höchsten bewertet, schreiben Sie für jedes eine Fitness Function und sorgen Sie dafür, dass sie schnell und zuverlässig sind, bevor Sie weitere hinzufügen. Ein Dutzend vertrauenswürdiger Prüfungen ist mehr wert als hundert, die zufällig fehlschlagen.

Nutzen Sie bei bestehenden Systemen eine Ratsche. Verletzt eine Codebasis eine Regel bereits, erfassen Sie die aktuellen Verstöße als Baseline und lassen Sie nur neue scheitern; verschärfen Sie die Baseline, während das Team die Schulden abbaut. Dasselbe funktioniert für die Performance: Bei Regressionen über eine vereinbarte Marge gegenüber dem letzten Release scheitern, während man auf das Ziel des Szenarios hinarbeitet.

Machen Sie Schwellenwerte explizit und geben Sie ihnen Verantwortliche. Halten Sie Schwellenwerte in versionierter Konfiguration neben einem Verweis auf das ADR, das sie begründet, mit einem namentlich genannten Verantwortlichen. Schlägt eine Fitness Function fehl, entscheidet der Verantwortliche zwischen Codekorrektur und Regeländerung, und die Entscheidung wird dokumentiert. Behandeln Sie eine Fitness Function, die häufig übergangen wird, als Befund: Entweder ist die Regel falsch, oder die Architektur steht unter echtem Druck.

Halten Sie die Pipeline schnell. Atomare Prüfungen gehören in jeden Build; schwere holistische Prüfungen wie zehnminütige Lasttests laufen nächtlich, vor dem Release oder auf dem Release Candidate. Kontinuierliche Prüfungen in Produktion brauchen dieselbe Sorgfalt wie jeder Alarm: an Auswirkungen auf Nutzer gekoppelt, mit einem Runbook und still, wenn nichts falsch ist.