Clean architecture is not a strategy
By Daniel Farré Manzorro ·
Everyone agrees that business logic should be explicit —defined in code, with a clear business layer. Where people disagree is on what that actually means.
The clean architecture crowd will tell you that if you use Django, your business logic will end up coupled to your database backend. Your domain will get entangled with your persistence logic. You won't have a pure business layer.
They're right.
But that's not the problem.
You can decouple everything from everything —and still have no idea what your business actually is.
The real issue isn't Django. It's building fat models —defining all your logic inside framework models, not because Django forces you to, but because nobody defined the boundary. And to be fair: decoupling everything isn't always worth it. Sometimes the cost-benefit doesn't add up, and you don't need a system that's fully agnostic of its environment.
You may end up with a perfectly structured codebase and still have no business logic established at all.
Because architectural purity is not the same as conceptual clarity.
Which brings me to the actual problem.
In most systems, business logic is not established. It accumulates.
Pricing exceptions. Manual overrides. Approval flows. People who remember why something works the way it does. At some point, all of that gets treated as if it had been intentional.
It wasn't.
Clean architecture doesn't fix that. It just organizes it. You can follow DDD with full rigor and still end up with cyclic dependencies —because no pattern forces you to define your processes consistently. No framework tells you how to decouple responsibilities. That's something you have to know how to do. Without that, you won't converge to a stable system.
What actually matters is whether your business abstractions are explicit —defined, named, understood, revisable. Not whether they are independent of a framework.
In Ficus, business entities are defined separately from how they're stored —not as clean architecture orthodoxy, but as a deliberate constraint. The two ends of the abstraction chain are kept apart. That's what lets the business model be seen, questioned, and changed.
The intelligence doesn't live in the framework. It doesn't live in the architecture pattern.
The framework provides generic infrastructure. The business logic is yours to define —and that's the part nobody can do for you. What Ficus provides is everything underneath: the structural layer your business sits on, so the business is the only thing you have to think about.
The intelligence lives in whoever can tell the difference between a rule and an accident.