Fitness Functions

An objective, usually automated, test that measures whether an architecture characteristic is being maintained as the system changes: performance budgets, dependency rules, security checks, coupling limits. Borrowed from evolutionary computing, a fitness function scores how close the architecture stays to its goals.

Why it Matters

Architecture characteristics erode silently as code changes unless something guards them. Fitness functions turn "the system should stay fast and modular" into checks that fail when it does not, making evolution safe and architectural intent enforceable rather than merely aspirational.

Signals

• Architecture qualities checked only manually, or discovered broken in production.
• "We agreed module A must not depend on B" with nothing enforcing it.
• Performance regressions found late, by users.

Benefits

Continuous protection of architecture characteristics, architectural rules made executable, and safe, guided evolution instead of decay.

Risks

Measuring what is easy rather than what matters; fitness functions that are flaky or ignored; a false sense of safety from checks that do not reflect the real characteristic.

Tensions

Every fitness function is itself code to maintain, and over-constraining the architecture can block legitimate change; you trade some freedom for protection.

Examples

A build check that fails if a layer imports from a forbidden layer; an automated test asserting p99 latency stays under a budget; a scan that fails the build on a critical dependency vulnerability.