Testable design

Every architecture makes claims: this is isolated, that scales, this can be replaced, that boundary holds. Testable design is the discipline of stating those claims so they can be shown to be false.

What it means in practice

• Architectural rules are executable. “The domain must not import the framework” belongs in a test that fails, not in a paragraph nobody re-reads.
• Contracts are verified from both sides. The provider proves it honours the contract; the consumer proves it only relies on what the contract promises.
• Boundaries are testable in isolation. If a component can only be exercised with the whole system running, its boundary is theoretical.
• Non-functional claims get non-functional tests. A latency or resilience budget nobody measures is an aspiration.

Falsifiable, not proven

The point is not to demonstrate the architecture is right — that is not available. It is to make being wrong cheap to discover. A design whose claims cannot fail a test cannot be checked at all, and will drift from the running system without anyone learning about it.

Where it meets the other principles

Architecture as code puts the claims where a pipeline can reach them. Contracted design makes the boundary claims explicit enough to check. Testability is what turns both into feedback.