Djangoモデルクラスからドメインクラスを切り離す

Question

私は構築中のWebアプリケーションのOO分析と設計を完了し、実装に着手しています。 PythonとWeb開発フレームワークDjangoを使用してシステムを実装するように設計が決定されました。

永続性が必要なドメインエンティティクラスの実装を開始したいと考えています。 Djangoは永続性のためにDjango ORMを使用するためにDjangoモデルクラスから継承されたクラスとしてDjangoにこれらのクラスを実装させるように思われます。しかし、これは私のクラスのエンティティと永続化機構との間の結合が強すぎるようです。ある段階でDjangoを捨てて別のWeb開発フレームワークを使用したい場合や、代わりにDjangoのORMを捨てたい場合はどうなりますか？今度はドメインエンティティクラスを一から書き直す必要があります。

ドメインクラスをスタンドアロンのPythonクラスとして実装し、すべてのビジネスロジックをこれらのクラスにカプセル化してから、ブリッジやアダプタなどのデザインパターンを使用して永続ストレージを委任する方がよいでしょう。これらのドメインクラスはDjango ORMに、例えばこれに対して適切に設定されたDjangoモデルクラスを介して。

誰でもこれを行う方法についての提案はありますか？私は人々がDjangoモデルクラスから継承したクラスとしてドメインクラスを実装し、このクラス内でビジネスロジックを混在させるだけであると思っています。これは、行の変更、メンテナンス、再利用性などのための良い考えではありません。

Answer 1

まあ、Djangoの基本モデルクラスを継承する方法です。これは「アクティブレコード」パターンです。あなたのdjangoモデルは、あなたがビジネスロジックと一緒にCRUDとクエリメソッドをすべて持っています（あなたがもちろんそれを追加することを決めた場合）。これはJavaの世界ではアンチパターンと見なされますが、クールなことは開発を本当に速くスピードアップできることです。

Answer 2

真剣にあなたはちょうどDjango ORMを捨てるつもりはないと思いますが、それ以外のものはすべて保持していますか？または、もしあなたがDjangoを完全に捨てれば、あなたのコードのはまだ適用されますか？

あなたがDjangoを捨てた場合、あなたはすべてのテンプレートを書き直さなければならないと不平を言うことはありません。もちろん、それは期待されるでしょう。では、なぜプレゼンテーションレイヤーはフレームワークにバインドされても、永続レイヤーにバインドされても問題ありませんか？

この種の事前分析は避けるべきです。 DjangoはRADツールであり、迅速で反復的な開発に最適です。大企業の多くが証言するように、すべてのものについて、強力で長寿命のアプリケーションを構築することができます。しかし、それはJavaではなく、「エンタープライズ」ではなく、特にOOの原則には合致しません。 Pythonの世界では、これはバグではなく機能として見られます。

Answer 3

異なる永続化メカニズムが必要な場合は、「モデルを最初から書き直す」必要はありません。 activerecordスタイルの永続性システムの全体的なポイントは、モデルクラスに最小の制約を課し、ほとんど透過的に動作することです。

本当に心配している場合は、クエリを独自のメソッドに依存するコードを抽象化してください。

Answer 4

Djangoモデルとドメインクラスのデカップリングには実装されたソリューションはないと思いますが、少なくとも私は見つけられませんでした。実際、私が知っているようなデカップリングを持つ唯一のORMは、Smalltalkの世界にしか存在せず、GLORPと呼ばれています。これにより、ドメインクラスを変更することなく、リレーショナルDBにドメインモデルを保持することができます。私は現在、Django ORMから切り離すために同様のアイデアを実装しようとしています。私の動機は、現在のDBテーブルとドメインクラス間の強力な結合が、ソフトウェアの進化をひどく傷つけることです。成功すれば私は再び投稿します:)