Put business logic in entity

I have the DoctrineEntity object Extend the DomainModel object. And while the controllers may actually receive DoctrineEntities, they only operate on the DomainModelInterface.

... namespace DomainModel;interface ArticleDomainModelInterface ...interface ArticleDomainModelRepositoryInterface ... // create, find, save, commitclass ArticleDomainModel implements ArticleDomainModelInterface... namespace Doctrine;class ArticleDoctrineEntity extends ArticleDomainModelclass ArticleDoctrineRepository implements ArticleDomainModelRepositoryInterface... namespace Memory;// Usually dont need a memory article objectclass ArticleMemoryRepository implements ArticleDomainModelRepositoryInterface

All model creation and persistence are done through a repository. The controllers and other related services are only aware of the ArticleDomainModel methods. This gives you a nice separation and allows using different repositories for testing or for supporting different persistence mechanisms. It also allows using value objects in your domain model while still persisting them with Doctrine 2.

However, in php, I do struggle with the notion of what sort of useful business logic can actually be put in the domain model objects themselves. I tend to end up with most of the logic in services. And that is because most of my php applications are heavily crud oriented.

There is also the question: should controllers themselves have access to domain model objects?

One of the main developers of Doctrine 2, Benjamin Eberlei, has a number of blog posts on this subject. All of his articles are worth reading in detail. Here are some:

http://www.whitewashing.de/2013/07/24/doctrine_and_domainevents.htmlhttp://www.whitewashing.de/2012/08/22/building_an_object_model__no_setters_allowed.htmlhttp://www.whitewashing.de/2012/08/18/oop_business_applications__command_query_responsibility_seggregation.html