👋 Hey {{first_name|there}},
Your architecture rules are decaying with every pull request, and nobody notices until something breaks. Here's how to make them self-enforcing.
Why this matters / where it hurts
You've been in this review. Someone opens a pull request, and a senior engineer leaves a comment: "This service shouldn't call the database directly. It needs to go through the repository layer." The author fixes it. Two sprints later, a different developer does the same thing. Nobody catches it. Three months in, your "clean architecture" has seventeen shortcuts baked into production, and the next refactor takes twice as long because nobody knows which violations are intentional and which are accidents.
The real failure mode isn't bad developers. It's that architecture rules live in people's heads, or maybe in a wiki page nobody reads after onboarding week. Code review catches some violations, but reviewers get tired. They get busy. They approve things on Friday afternoon that they'd flag on Tuesday morning. And the rules that seemed obvious to the team that wrote them are invisible to the three engineers who joined last quarter.
In Lesson #34 on the Distributed Monolith, we talked about how service boundaries erode when coupling creeps in unnoticed. Fitness functions are how you stop that creep at the source, before it reaches a pull request comment, before it reaches production.
🧭 The shift
From: Architecture rules are documented conventions enforced by human reviewers during code review.
To: Architecture rules are executable tests that fail the build the moment someone violates them.
The idea comes from evolutionary architecture. A "fitness function" is just a test that evaluates whether your system still meets a specific architectural property. Not a unit test for business logic. A test for structural rules. Does the domain layer import anything from infrastructure? Does a controller class talk directly to the database? Does a new module introduce a circular dependency? These are objective, binary questions. A machine can answer them faster and more consistently than any reviewer.
The term sounds academic, but the implementation is practical. You write rules in code, they run in CI, and they either pass or fail. No opinions. No "well, I think we should..." conversations. The build is green, or it isn't.
If a rule matters enough to put in a design doc, it matters enough to put in a test.
Fitness functions should run on every commit, not quarterly in a review meeting.
Start with the rules your team already argues about in pull requests. Those are the ones that need automation first.
📘 New: The Career Guide got an upgrade
I just finished a major update to the From Developer to Architect career guide. It now includes a self-assessment rubric, a week-by-week 90-day growth plan, architecture artifact templates, and interview prep frameworks. If you're actively working toward a Staff, Tech Lead, or Architect role, this is the structured roadmap.
Free download here: https://www.techarchitectinsights.com/from-developer-to-architect-free-career-guide