views:

371

answers:

1

I'm thinking of implementing a Domain Driven Design approach (similar to the one described here), but want to integrate it with the Doctrine ORM. Has anyone had any success doing anything like this?

My initial instinct was to use Doctrine as the DAO layer, but it seems a a bit convoluted for Doctrine to map my database fields, and my entity objects map to (essentially) the same set of fields on the Doctrine object.

My original goal was to separate all my DQL/query logic from my domain Entities, but now I'm feeling a little lost in design-pattern land at the moment.

I know Doctrine 2 is supposed to provide a much more friendly approach to DDD techniques, but I'm not sure I want to wait that long. Does what I want to do make sense, or should I find another approach?

Thanks.

+1  A: 

Doctrine is, in my opinion, imperfect for DDD because of the lack of a Repository class. Doctrine supports patterns such as Table Data Gateway and Active Record which, whilst good patterns for certain problems, aren't necessarily the best choice for 'classic' DDD. You can, however, work around these deficiencies.

One option is to derive from Doctrine_Table and use that as a poor man's repository. For example, if you have a class called 'BlogPost', you might have a table class 'BlogPostTable', inheriting from Doctrine_Table. You can then add methods such as 'findByCategory' to the BlogPostTable class, keeping such logic separate from your domain objects (which inherit from Doctrine_Record). It's not exactly the same as the patterns advocated by 'pure' DDD, but it's close enough.

Even without the exact same design patterns, you can still use the central insights of DDD. The main one is the Ubiquitous Language, the concept of trying to describe your domain using precise language that is readable by domain experts and developers alike.

Rob Knight
Thanks. I think this response reflects my experiences completely. Doctrine's square peg just doesn't seem to fit correctly into DDD's round hole. I ended up treating my Doctrine_Record classes as my Entities, and implemented a basic Repository class using Doctrine_Table as a DAO layer. While it does give me most of the separation I wanted, it does feel a bit clumsy, or over-architected, as the Repositories feel a bit redundant at times.
Bryan M.