Make sure that these books are talking about domain driven design. As Jeff Mott indicated, under no circumstances will domain objects know about how to persist themselves. Furthermore, DDD is all about complex business rules. The notion that it would be used for "common business logic" is an oxymoron.
You actually make a good point on DDD and business logic, so the question is how do you make sure your software/application will have such worthwhile business logic? Lets say I work on an RPG software or something similar to this, does this mean my application will have good amount of business logic since the system can be rather complex. Or for a blog software, a forumware, or a social networking software, do they need DDD or not for their level of business logic complexity?
This is why DDD is probably not appropriate for most php applications.
I have a soccer tournament app. During a tournament, teams are divided into groups and then play the other teams within their group. Winners of each group move on to the next round. Determining the winner of a group can actually involve some complex logic based not only on who wins but number of goals, misconduct etc. You would think that it would be a perfect candidate for DDD.
But I could never get it to fit. I end up querying a set of games and then passing those games into a winner calculator service. The game object (which you would think would be a great business object) is really just an anemic data collector It know who the teams are and what the score was but that's about it. All the tie breaking stuff ends up in the winner service. So it's basically a CRUD application and does not qualify as DDD.
Someday I'd like to figure out how to change that but no luck so far.
As far as blogs/forums/friends etc goes, I'll leave it up to you to try and figure it how to add the complex business rules to the business objects themselves.