Fitness Functions and Evolutionary Architecture

What a fitness function is

The term comes from Neal Ford, Rebecca Parsons, and Patrick Kua’s book Building Evolutionary Architectures (O’Reilly, 2017). They borrowed it from evolutionary computing, where a fitness function scores how well a candidate solution satisfies the problem’s requirements.

In architecture, a fitness function is any mechanism that provides an objective, automated assessment of whether an architectural characteristic still holds. It is not documentation. It is not a code review checklist. It runs in CI and produces a pass or fail.

Architectural characteristics — sometimes called “ilities” — are the non-functional properties the architecture must preserve:

• Modularity: no module imports from another module’s internals
• Latency: the p99 response time of the billing API is under 200ms
• Cyclic dependency freedom: no package-level cycles between modules
• Security: no sensitive data appears in log output
• Scalability: the system can process 10,000 invoice generations per minute

A fitness function turns these from aspirations into build gates.

Atomic vs holistic fitness functions

Ford, Parsons, and Kua distinguish two dimensions of fitness functions: scope and frequency.

Atomic fitness functions test a single architectural characteristic in isolation:

• “No cyclic dependencies between modules” — a single ArchUnit rule
• “No direct imports from another module’s internal package” — a ts-arch or ESLint rule
• “All public API methods return within 50ms in unit tests” — a performance assertion in the test suite

Holistic fitness functions test a combination of characteristics that only emerge together:

• “Under a 10,000 RPM load, the system maintains p99 < 200ms AND error rate < 0.1% AND no OOM errors” — a load test in CI
• “The deployed system passes security scanning AND dependency audit AND no cross-boundary access in production traces” — a composite gate

Most teams start with atomic fitness functions because they are cheap to write and fast to run. Holistic functions are more expensive but catch emergent failure modes that atomic tests miss.

Triggered vs continuous fitness functions

The second dimension in Ford/Parsons/Kua is frequency:

Triggered fitness functions run on demand — in CI, on merge, on a schedule. They are appropriate for checks that are expensive to run (load tests, full security scans, integration tests against a staging environment) or that test properties that can only be verified against a built artifact.

Continuous fitness functions run on every change, in the development loop, as fast as possible. They are appropriate for structural checks (dependency rules, cyclic dependencies, import restrictions) that can be evaluated against source code without building or deploying.

For the billing platform’s boundary violation problem, a continuous fitness function is correct: the ArchUnit or ts-arch check runs in the unit test suite on every commit, failing immediately when a violation is introduced. There is no lag between violation and detection.

A load test that verifies p99 < 200ms under 10,000 RPM is necessarily triggered — it requires a running environment and takes minutes to execute. It runs nightly or before a release, not on every commit.

Implementing fitness functions: practical examples

ArchUnit (Java) — dependency direction:

// Fail the test if any class in billing imports from ordering.internal
@AnalyzeClasses(packages = "com.platform")
class ModuleBoundaryTest {
  @ArchTest
  static final ArchRule billingMayNotImportOrderingInternals =
    noClasses().that().resideInAPackage("..billing..")
      .should().dependOnClassesThat()
      .resideInAPackage("..ordering.internal..");
}

ts-arch (TypeScript) — no cycles:

// Fail the test if any circular dependency exists between modules
describe("architecture", () => {
  it("has no cyclic module dependencies", async () => {
    const result = await tsarch.FileSystem
      .fromConfig("tsconfig.json")
      .onlyFiles(["src/**/*.ts"])
      .noCycles();
    expect(result).toEqual([]);
  });
});

Latency budget (unit test assertion):

it("invoice generation completes within 100ms", async () => {
  const start = performance.now();
  await billingService.generateInvoice(testOrderId);
  const elapsed = performance.now() - start;
  expect(elapsed).toBeLessThan(100);
});

The commonality: each is a test that produces a pass/fail. Each runs in CI. Each catches a specific architectural property. The property was previously only maintained by human convention; the fitness function makes it a machine-enforced invariant.