📅 Join me: Clean Architecture for Backend Developers on Wed 26th Aug, 5:00 - 6:30 PM (CEST)
🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
The first rule Uncle Bob lists in The Clean Architecture is:
“Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.”
Frameworks as tools. That’s reasonable.
But it usually gets repeated as something much stricter.
No annotations. No libraries. No framework classes.
Nothing.
The domain must be completely pure.
I disagree.
Not because frameworks should control your business logic.
They shouldn’t.
But not every framework dependency is automatically a problem.
Some dependencies genuinely make your code harder to change.
Others simply make your code easier to write.
There’s a huge difference between:
@Service@Component@Repository
and
@Entity@Id@Column@ManyToOne
The first barely affects your domain. The second fundamentally shapes it.
The strict reading treats them the same.
A class with an annotation, a service managed by Spring, a repository injected by a framework — all bad.
The result?
They end up building systems that are technically “pure” but harder to work with.
Because the goal of architecture is not to remove every dependency. It is to remove the dependencies that dictate how your business rules are written.