Fitness functions
A fitness function continuously checks whether an important architectural feature is adhered to. It can be carried out static, dynamically or on the basis of measurable operating data.
- RuleThe property that should hold.
- Check runAutomatically on every change.
- LocationReport violation with location.
Context
Why this is important
Architecture rules that are only in the head or document are violated unnoticed. An automated inspection makes violations immediately visible. How deviations arise in the long term describes architecture erosion.
This building block deals with automated property checks. Architecture erosion describes deviations; architecture review assesses design and risks in context.
At a glance · Automatically check architecture rules
Check run for module access
The shop maintains dependencies between order, shipping and invoice modules within defined module contracts. An automatic test marks unauthorized database accesses.
This is how you read the picture
- Rule The line 'Modules only interact via contracts' above the changes.
- Check run The result 'build green' or 'build red' after selecting a change.
- Location The message for 'build red' names module and access, such as shipping to order table.
RuleModules only interact via contracts.
Build redBuild red: direct access to the order table reported, location named in the shipping module.
Benefits & limitations
Helps if:
- Early structural feedback helps when many contributors make frequent changes.
- Critical quality characteristics require repeatable proof across commit, release or operational boundaries.
Boundaries
- A passing check establishes only what it measures; other properties require independent evidence.
- Outdated thresholds block meaningful changes; assumptions and exceptions are regularly reviewed with those responsible.
- Import rules cannot detect data or runtime coupling; Architecture erosion explains how deviations arise.
In practice
- Make the property measurable. Define a testable rule or measurement, its system scope and the desired behaviour. State which conclusion a passing result supports. This produces a concrete fitness claim with a measurable scope.
- Choose the verification method and frequency. Match checking cost to an appropriate execution schedule and set the threshold, environment and data basis. Ensure that owners can interpret failure messages. This makes feedback effective and proportionate.
- Connect each finding to an action. Show the violated rule, measurement scope and business consequence for each result. If a module cycle appears, examine the change history using Software Analytics before enforcing a fitness rule against the confirmed access.
- Maintain exceptions and rule changes. Record exceptional cases with an owner, deadline and alternative evidence. Review the rule when the quality goal or architecture changes. This keeps the verification contract current and its uncovered areas visible.
Read the detailed explanation
A fitness function turns an architectural property into a repeatable check. Static rules can control dependencies; runtime checks can measure response behaviour or recovery. Measurement method, scope and threshold determine what a result establishes. These checks make Quality attributes concrete and help detect Architecture erosion early.
Checks differ in cost and frequency: fast rules can run on every change, while expensive load or restore rehearsals run periodically. A result covers only its defined measurement scope. Exceptions need owners and expiry dates; architecture rules are updated when their assumptions change. This provides automated feedback without claiming to prove every aspect of architectural quality. Thresholds need a business rationale and clear messages. False positives encourage bypasses, while false negatives reveal deterioration too late. Each check should clearly expose the violation and its consequence for a change or release.
The term comes from “Building Evolutionary Architectures” by Neal Ford, Rebecca Parsons and Patrick Kua.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which results do 'Invoice reads order table via its own query' and 'Order changes its own table internally' show?
View the solution with justification
The first change gives 'build red', the second 'build green'.
ApplyingTransferred to a new situation
The shipping module should change the order status. How does the build stay green?
View the solution with justification
The status change is requested via the order contract instead of writing directly into the order table.
EvaluateWeighing an alternative
The check run should only warn, not stop the build. What speaks for it, what speaks against it, and what do you recommend?
View the solution with justification
Advantage: less disruption to the flow. Disadvantage: warnings get ignored and violations seep in. Recommendation: stop the build and keep known legacy cases as documented exceptions.
Explore further
These building blocks continue the thoughts of this page.
References
- Governing data products using fitness functions (opens in new tab)Shows verifiable architectural goals and automated fitness functions using the example of data products.
- ArchUnit – User Guide (opens in new tab)Shows executable rules for dependencies, layers and architectural conformity.
- Thoughtworks – Fitness function-driven development (opens in new tab)Explains continuous feedback about architectural conformity through executable fitness functions.
- Markus Harrer · Software Analytics (opens in new tab)Software data as a basis for questions, investigations and sound improvements.