従来の ASP から派生して、現在、比較的大きな Django アプリケーションを開発しています。このプロジェクトのコードを扱いやすい部分に分割する方法を見つけようとしています。
議論のために、USERS と多対多の関係にある CLIENTS があり、これらのユーザーには 1 つの ROLE があり、各役割には RIGHTS と多対多の関係があるとします。
現在、これらすべてを「backoffice」という 1 つのアプリにまとめています。
欠点は、backoffice アプリ内の forms.py と views.py に、これらすべてのエンティティのクラスが含まれていることです。アプリケーションは確実に拡大するため、これらのエンティティのコードをいくつかのファイルに分けたいと考えています。したがって、それらは実際には別個のアプリではありませんが (私が思うに)、プロジェクトのバックオフィス部分の異なる部分を扱っていることは確かです。
インターネットで調べたところ、2 つの意見があるようです。1つは、models.pyやviews.pyなどを分割して、フォルダ/モジュールにする方法です。これらのフォルダーには、clients.py/users.py/roles.py などを含めることができます。これにより、アプリはそのまま維持されますが、コードは分離されます。最終的には、多数のファイルを含む 1 つの大きなアプリが作成されます。
もう 1 つのオプションは、コードを分割し、クライアント、ユーザー、およびロールを個別のアプリに変え、現在ある「バックオフィス」アプリを完全に削除することです。Django は小さなアプリへの分割を推奨していますが、これらは実際には個別のアプリではなく、クライアント ユーザーとロールは密接に関連しており、私たちが作成しているメンテナンス ツールはこれを反映しています。
私は実際には、「バックオフィス」アプリ内に小さな (サブ) アプリを作成することから始めましたが、ここでそれはうまくいかないことがわかりました。
問題は、アプリは再利用を促進する必要があり、私たちが構築している大規模な Web アプリには多くの部分が絡み合って相互に依存しているということです。現実世界で意味のある、より小さな再利用可能なパーツに分割する現実的な方法はありません。
ですから、問題は本当にです。この例でユーザー/クライアント/ロールのコードを分離するための推奨される方法と、いずれかの方法の長所/短所は何ですか? たぶん、私たちが見つけていない完全に別の方法さえあるかもしれません...
御時間ありがとうございます。