Domain Driven Design in Laravel 4 - Part 3

Two steps forward, one step back! I have been going around in circles a little bit trying to integrate the concept of clean and simple domain entities with the Eloquent ORM.

Eloquent is a beautiful thing, so it seems such a shame not to use it by default if buying into Laravel, however there seems little point in letting Eloquent hydrate your models and then taking that collection and using it to hydrate entities, seems like pointless double handling to me.

So ... after briefly looking at the alternative of using the repository pattern with Query Builder instead of Eloquent, and hydrating entities from Query Builder results I realised that I was wasting my time re-inventing the wheel.

Once I started thinking about how to write the full persistence abstraction layer, worrying about details like generation of proxy objects for lazy loading of object graph, etc. I realised that these nuts had already be cracked by Doctrine 2. So the next step in this little DDD journey is to take a sidetrack to look at using Doctrine in place of Eloquent.

So sorry, nothing concrete yet in terms of sample code, but watch this space ....