An architecture rarely becomes unmanageable in one release. Today one module reads another module's table directly. Tomorrow another gains an unnecessary dependency. A month later a critical request path is getting slower. Every local decision may look reasonable. Together they erase the boundaries the system depended on.
Architecture Fitness Functions turn selected architectural properties into checks that can reveal drift near the change that caused it, instead of at a much later review meeting.
Choose the property before choosing the test
Suppose the team has agreed that payment logic must not depend directly on the presentation layer. That dependency rule can be checked in CI. Or a customer-facing operation has a latency objective that needs monitoring in tests and production.
Those are different kinds of evidence. Static dependency checks do not prove that the payment system is reliable under load.
Where an automatic check pays for itself
The approach works best for important boundaries that can be accidentally violated and are hard to notice in ordinary code review. Multiple services slowly accessing one another's private databases can destroy future delivery independence.
A check can reject new forbidden dependencies or at least make them visible before deployment. That means an important agreement no longer depends entirely on someone remembering a diagram from two years ago.
Tests can preserve a bad decision too
Architecture rules age. A check may produce false alarms, block a necessary migration or protect a design whose original assumptions no longer hold.
Every important rule therefore needs an owner, an explanation, a controlled exception path and occasional review. Otherwise teams learn to work around the test and eventually switch it off.
Not every architectural quality can be reduced to a metric. Whether a business workflow is understandable or ownership is clear still requires human judgement. Automation is support, not a substitute.
Start with one expensive failure mode
I would choose a boundary whose violation has already cost time or caused regressions, then make it observable. The test is useful only if someone knows what to do when it fails.
An ADR can capture why the boundary exists; a Fitness Function can help keep it true.
A Fitness Function earns its place when it prevents expensive architectural decay. If nobody can explain its purpose or the action it should trigger, it has become process overhead.