Architectural Fitness Functions

Overview

A fitness function is any mechanism that gives an objective assessment of how close a system is to an architectural goal. The term comes from evolutionary computing and was applied to architecture by Ford, Parsons, and Kua.

Fitness functions fall into several types: atomic versus holistic, triggered versus continuous, and static versus dynamic. A unit-level dependency check is atomic and triggered. A load test of a whole flow is holistic. A production latency alert is continuous.

How it works

Pair each characteristic with a measurable check and a place to run it.

// ArchUnit-style dependency rule
noClasses().that().resideInAPackage("..domain..")
  .should().dependOnClassesThat()
  .resideInAPackage("..infrastructure..");

# production check
alert: p99_latency_checkout > 400ms for 10m

Start with the two or three characteristics that would hurt most if lost, such as module boundaries, data residency, and tail latency. Add a function only when a violation is both plausible and costly, and give each function an owner and a documented reason it exists.

Pitfalls

• Measuring what is easy rather than what matters
• Letting failing checks stay red until people ignore them
• Writing functions for every concern instead of the critical few
• Forgetting to retire checks when the target architecture changes

Key takeaways

• Tie each function to a stated architectural goal
• Run structural checks in CI and operational checks in production
• Keep the set small and trusted
• Update thresholds deliberately, with an ADR