This is the downfall of Active Record. If you use Eloquent you are going to be coupled to the ORM, Active Record is meant for fast development and the downside is the coupling. A data mapper will provide better abstractions but you lose a (small amount) of productivity. Also I'm not sure how hard any of the data mappers are to integrate with Laravel. I know Doctrine can be used but I haven't done it within Laravel yet.

Thanks for the response. Will checkout Doctorine for sure.

You don't need to use Eloquent, you can just as easily use DB in your own model. The downfall is that you need to build everything yourself. If you extend Eloquent you have stuff like first() and you will need to recreate them in your own Model using the DB class.

Another approach would be to not directly return the User model in your repository but for example a plain array (or stdClass)

Would a valid approach be to have an interface that my eloquent entities implements?

Than i could use the eloquent entities but still future proof the project simply by creating new entities that implements the interface if there comes a time when i don't want to use Eloquent anymore.

thats what i'm looking to add in a current project. class EloquentUser extends Eloquent implements User

@matthisstenius: I was having a similar problem when it came to a project we took on. I found this article by Philip Brown that helped tremendously. It explains how to decouple Eloquent from your Repository objects. Very good read.

http://culttt.com/2014/03/17/eloquent-tricks-better-repositories/

@pddevins // I think the article explains how to decouple the repository objects from the framework. It doesn't solve the issue with returning an Eloquent object. As you see on the article, the repositories simply return an instance of Eloquent object. The eloquent is still coupled with your entire application.

Interfacing eloquent objects is a good enough WORKAROUND, but it's not a solution. You're still allowing other Eloquent specific methods to be called.

@zenry // Returning an array should be used only for views IMO. Returning an array/stdClass for your business operations completely destroys OOP approach.

I think there is a mental trap lurking in this conversation. There's no reason you absolutely must use the Hexagonal pattern for the entire application, I think it is dangerous to buy into any architecture as a matter of dogma, and indeed the ORM coupling takes you outside of the Ports and Adapters pattern. However, there is no reason you can't design the rest of the application using it and maintain the wonderful convenience of Eloquent by using the interface 'workaround' or Doctrine, or brew your own model to suit. There's not a perfect answer, there are always compromises. The article @pddevins linked to is a nice idea, love it.