Architecture Tests: Stop Trusting Your Architecture Diagram

Your architecture diagram says:

API → Application → Domain
         ↑
   Infrastructure

Your code might have other ideas.

Someone adds:

Domain → Infrastructure

Then:

Application → API

Six months later, the diagram is still beautiful.

One way to protect important boundaries is with architecture tests.

For example, you can define rules such as:

Domain must not depend on Infrastructure

Application must not depend on API

Controllers must not access repositories directly

Then run those rules as part of your test suite and CI pipeline.

Architecture tests are useful for enforcing things such as:

• Layer dependencies
• Namespace boundaries
• Module isolation
• Naming conventions
• Dependency restrictions
• Clean Architecture rules

They don't prove that your architecture is good.

They prove that specific structural rules you decided were important are still being followed.

Documentation describes the intended architecture.

Tests can check whether the code agrees.

If an architecture rule matters enough to put on the diagram, it might matter enough to test.