Clean Architecture: The Dependency Rule Isn’t Optional

Why your domain logic keeps breaking (and how to fix it)

👉 Reserve Your Spot for the 2026 ATDD Accelerator

---

I was trying to add a small feature to our order system.

Simple, right? Just a validation: “Orders over $10,000 require manager approval.”

Two hours later, I was deep in a mess:

• Domain entities glued to JPA annotations.

• Use cases directly calling repositories.

• Controllers scattered across three packages.

I thought: “How is anyone supposed to change this without breaking everything?”

Dependencies were everywhere, pointing the wrong way. Every small change became a massive headache.

The Daily Pain

• Changing a business rule? Better hope no one touched your domain logic with a framework dependency.

• Writing a test? Say hello to spinning up DBs, mocking everything, or manually handling try/catch just to check if something works.

• Refactoring? One wrong move and the system falls apart.

I realized: if your core logic depends on infrastructure or frameworks, everything else becomes fragile.

What Does “Depend” Mean?

You’ve got a dependency anytime you:

• Import a class

• Call a method

• Reference a concrete implementation

• Require a framework to compile

Red flags I see all the time:

• A use case importing Spring annotations ❌

• Domain entities referencing ORM ❌

• REST controllers sneaking into inner layers ❌

Use Case Depends on Infrastructure ❌