Doctrineをドメイン駆動設計で使用する

Question

私はドメイン駆動設計アプローチ（hereと同様）を実装することを考えていますが、Doctrine ORMと統合したいと考えています。このようなことを誰かが成功させましたか？

私の最初の本能はDoctrineをDAOレイヤーとして使用することでしたが、Doctrineがデータベースフィールドをマッピングするのに少し複雑で、エンティティオブジェクトがDoctrineオブジェクトの（同じく）フィールドセットにマッピングされています。

私の最初の目標は、すべてのDQL /クエリロジックをドメインエンティティから分離することでしたが、今はデザインパターンの土地で少し失われています。

私はDoctrine 2がDDDテクニックに対してはるかにフレンドリーなアプローチを提供するはずですが、私はそれを待っているとは思っていません。私がやりたいことは理にかなっているのですか、別のアプローチを見つけるべきでしょうか？

ありがとうございました。

Answer 1

Doctrineは、私の意見では、Repositoryクラスがないため、DDDのために不完全です。 Doctrineでは、Table Data GatewayやActive Recordなどのパターンをサポートしていますが、特定の問題のパターンは「古典的」DDDにとって必ずしも最良の選択ではありません。しかし、これらの欠点を回避することはできます。

1つの選択肢は、Doctrine_Tableから派生し、貧しい人のリポジトリとして使用することです。たとえば、 'BlogPost'というクラスがある場合、Doctrine_Tableを継承したテーブルクラス 'BlogPostTable'があります。このようなロジックをドメインオブジェクト（Doctrine_Recordを継承したもの）とは別のものにして、BlogPostTableクラスに 'findByCategory'などのメソッドを追加することができます。 「純粋な」DDDによって提唱されたパターンとまったく同じではありませんが、それは十分に近いです。

全く同じデザインパターンでなくても、DDDの中心的な洞察を引き続き使用できます。主なものはユビキタス言語で、ドメイン専門家と開発者が同じように読むことができる正確な言語を使用してドメインを記述しようとするコンセプトです。