Morphia や Hibernate などの永続化フレームワークは、ドメイン オブジェクトの注釈に依存して魔法を実行していることに気付きました。あるレベルでは、これは永続化の問題をドメイン レイヤーに挿入しているように思えますが、これは回避するよう努めるべきものです。
これは、おそらく外部構成ファイルを使用するか、ドメイン モデルから DTO を分離することによって回避しようとする必要があるものですか? それとも、パーシスタンス層とドメイン層の間のこのわずかな漏れは、一般的に許容できると見なされているのでしょうか?
SpringとHibernateを使用する既存のシステムでの最近の反復では、同様の問題で動き始めました。Hibernateモデルを最初に実装したとき、私はサービスクラスのアプリケーションロジックをデータアクセスオブジェクトを介して永続ロジックから分離するように努めました。昨年、新しいシステムを構築するときに、ほとんどの永続オブジェクトがドメインオブジェクトとして機能することを許可しました。これが、適切なソリューションであったためです。
しかし、私はビジネス要件の変化を考慮してこの同じシステムを再設計しており、これらの懸念を分離することに再び傾いています。新しい設計を始めてまだ数日ですが、メモリ内の懸念オブジェクトを表す1つのオブジェクトを使用し、その状態の変更をデータベースに格納するために別の永続性ベースのオブジェクトを使用することをすでに望んでいます。たとえば、トランザクション間Leadで存続する永続性と並列性があります。ActiveLead
これが最善の方法であるとはまだ確信していませんが、腸のレベルでは理にかなっています。私は、標準のCRUDの簡略化に関係なく、データベーストランザクション全体でメモリに常駐し続けるオブジェクトの永続性にとらわれない（いや、永続性にとらわれない）セットのコレクションを持ちたいと思っていました。しかし、最終的にはすべてのデータベース操作がCRUDとして実装されることを理解しています。2つの世界は衝突しなければならず、秘訣はそれらを調和させて踊らせることです。
ドメインオブジェクトのHibernateアノテーション？これは、私の見解では、実装のしやすさとメンテナンスのしやすさの間の微妙な妥協点です。
私は最近、独立した永続層を持つかなり複雑なシステムに取り組んでいましたが、これはお尻の大きな痛みであり、保守性が非常に悪かったです。あなたは基本的に、YAGNI の原則と単一責任の矛盾を見ています。私の意見では、YAGNI はより重要なものです (残念ながら、より頻繁に無視されるものでもあります)。
ほとんどの場合、ORM を使用している場合は、ドメイン オブジェクトを直接永続化する方がはるかに優れています。象牙の塔の議論を除いて、それらを分離する理由はありません)。
確かに:実際の永続化 (ORM 関数の呼び出し) は、常に別のサービス/DAO レイヤーで行ってください。そうすれば、後で必要になった場合に、永続化レイヤーを簡単に導入できます。
簡単な答え: 永続的でリッチなドメイン オブジェクトが好きです。
長い答え:
ほぼ 10 年間、Spring と Hibernate を使用して 500k LOC のかなり大規模なシステムに取り組みました。最初は、"トランザクション スクリプト" (Fowler を参照) アプローチから始めました。これは、Hibernate を完全に信頼していなかったことが一因です。しかし、すぐに Hibernate を信頼するようになりました。かなり純粋な OO の以前のトレーニングのおかげで、ドメイン駆動設計アプローチと組み合わせた一時的な永続性を強く信じるようになりました。基本的に、私たちのシステムは ODBMS で支えられていると考えるようになりました (多くの小さなリークがあります :-))。
私たちのアーキテクチャを「ドメイン カーネル」と呼んだのは、DDD という本がまだ書かれていないからです。これは Hibernate の初期の段階であったため、ドメイン モデルは注釈で汚染されていませんでした。XML マッピングでは、持続性に関する別個の関心事が別個に保たれていました。
繰り返しになりますが、時間が経つにつれて、動作をドメイン層にプッシュダウンする方法が改善されました。コンパイル時の依存関係で強制される、かなり伝統的なコントローラー-->サービス-->dao-->ドメイン階層化スキームがありました。時間をかけて私が観察したことは、このモデルが当社のシステムで非常にうまく機能したことです。これは、プランの設定、取引、会計、コンプライアンス テスト、販売、ブランディングなどを含む、401(k) プラン管理のかなり複雑なドメインのあらゆる側面を表しています。 (比較的) 透過的な「魔法のような」永続性を備えたリッチ ドメイン モデルは、ドメイン モデルの既存の機能に関して新しい機能を構築できるようにするための鍵でした。
当社のサービス レイヤーは、技術サービス (電子メール、ファイル I/O、キューイングなど) 間の相互作用のみを調整し、必要に応じて複数のドメイン パッケージにまたがるのに役立ちました。サービス層は、(Spring を介して) トランザクション境界も定義しました。サービスは、DTO またはプリミティブのみを受信または発行しました。多くの人は、DRY の中断としてそれを嫌っていますが、サービス インターフェイスとそれらを使用するコードを定義するときに、正直でいられることがわかりました。また、後でリモート操作を行うのも非常に簡単になりました。
このアプローチにより、非常に小さなチーム (私たちはスクラム チームでした) で高品質のソフトウェアを構築することができました。
したがって、私は永続ドメイン オブジェクトの信奉者だと考えてください。私の話が役に立つかどうかわかりませんが、共有したかったのです。
使用する永続化フレームワークが決まっている場合は、自分のドメインでアノテーションを使用すると思いますが、Hexagonalアーキテクチャと TDD に従う場合は XML の方が便利です。前もって特定のフレームワークでドメインにアノテーションを付けると、持続性の統合と結び付き、テクノロジー/フレームワークにとらわれないことを目的としてコア機能をテストできなくなります。
私の意見では、永続化レイヤーからドメイン オブジェクトを分離できるようにするためにドメイン オブジェクトを複製する必要はありません。複製コードを手元に置いて動作し、DTO と同じオブジェクトを使用することで完全に実行可能です。必要に応じて、いつでも個別のクラスを使用できますが、経験則ではありません。時間がかかるため、時間は貴重であることは誰もが知っています。
注釈が付けられた豊富なドメイン オブジェクトが望ましいと思います。Evans でさえ、サンプル アプリでこのアプローチを使用しています。彼は注釈の代わりに XMl を使用していますが、それでも同じオブジェクトを保持しています。
ドメインと永続性を分離する方がクリーンかもしれませんが、将来別のデータベース技術を選択できるようにするためだけにしないでください。それは複雑な地獄への道であり、ミスター YAGNI はあなたを噛むでしょう。