FW を使うのであれば FW の思想から逸脱したコードアーキテクチャを取らないほうがいいと思う

>●フレームワークのアーキテクチャに難があることが少なくない。一般に、フレームワークは依存性のルールに違反する傾向がある。フレームワークのコードを継承してビジネスオブジェクト（つまりエンティティ）に組み込めだなんて、とんでもない！フレームワークの作者は、円の最も内側にフレームワークを結合させたがっている。一度入り込んでしまえば、それを取り外すことはできなくなる。一度はめた結婚指輪は、ずっとあなたの指に残り続けるのだ。

●アプリケーションを作り始めた頃は、フレームワークが助けになってくれるだろう。しかし、プロダクトが成長するにつれて、フレームワークの提供する機能では手に負えなくなってくる。結婚指輪をはめたままでいると、フレームワークに邪魔されてばかりいる自分に気づくだろう。

●フレームワークが進化する方向が、あなたの望む道からずれてしまうかもしれない。自分にとって何の利益にもならない新バージョンへのアップグレードには躊躇するだろう。便利に使っていた機能が突然廃止されてしまったり、仕様変更されてしまったりすることだってあり得る。

●優れたフレームワークを見つけたときに、乗り換えたくなる可能性がある。

Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘. Clean Architecture　達人に学ぶソフトウェアの構造と設計 (Japanese Edition) (Kindle の位置No.4287-4298). Kindle 版.

この書籍はかなりアンチフレームワークではあるのだが、可能ならフレームワークとビジネスロジックが密結合にならないようにというのは同意している。これを実現しようとして、Django のような ActiveRecord に Clean Architecture の概念を持ち込んで、Domain Model と Django ORM Model を分離するみたいな実装をちらほら観測するが、個人的にはこれは避けたほうがいいと思っている

FW を使う以上、FW の思想に従ったほうが良く（この場合、Django Model が DB と密結合であることを犠牲にスピードを出して開発をするという思想）で、ここから逸脱したことをやり始めた途端に FW もビジネスロジックも不必要な外在性認知負荷が生じてしまう。

一度こういった FW を使ってしまった以上、FWの思想とは向き合い続けたほうがいい。そうでないなら FW を辞める選択肢を取ったほうがいいというのが自分の考え