Entities vs Domain Models?

Well I’ve heard many times that there is a difference between an entity object and a domain object(domain model), but even now I am still somewhat confused when it comes to the distinction between them. So can anyone please elaborate thoroughly on what is an entity as compared/contrasted with a domain model? And in what circumstances would you actually use an Entity rather than a rich domain model? Or can they be used collaboratively? I know thats a lot of questions, but hopefully someone clears my confusion before I start to implement my own ORM system for my PHP application/framework. Thx, and happy new year.

Unless some person came up with extra-specialized definitions, I’m pretty sure they’re largely the same thing. An entity is a domain model object.

I’d always thought that an entity was a domain object that had an identity (such as a user), whereas you can also have value objects, which are part of the domain model, but don’t have identity?

I think much of the confusion comes from the fact that different groups/patterns use the same term to mean/imply different things.

For the Domain Driven Design folks (http://en.wikipedia.org/wiki/Domain-driven_design), an entity is a domain model object with it’s own unique identity. The domain model also contains value objects which have no unique entity. In DDD, the domain is divided up in contexts. The same object might be an entity in one context and a value object in another. In any event, DDD domain objects are not supposed to be inherently persistable.

On the other hand, in the land of PHP, the most popular ORM is Doctrine 2. In D2 an entity is still described as an object with an identifier but it’s also mapped to a database and can be persisted.

Basically, when researching this stuff, you need to figure exactly what definition a given article is using.

It is possible in PHP to have DDD type model objects which can then be extended and persisted using D2 type objects. You just have to ask yourself if the separation is really necessary. Most PHP applications tend to be CRUD oriented with little business logic. So DDD is usually not worth the effort.

I see, thanks for the explanation guys. I thought entity were more like model objects in the data access/infrastructure layer while the domain model is the model in the domain/business layer. Guess the term itself is confusing since it is used in different contexts. If the correct interpretation for an entity is that it is a domain model with identity, does this mean that an entity object is associated with database tables with keys(primary or compound keys)? And the non-entity domain models(or value models) usually relates to data without keys? In this way, is it a good idea to create two subclasses for DomainModel class named EntityModel and ValueModel?

Actually my PHP software is more than just a typical CRUD oriented application, so I definitely look into the idea of DDD.

Personally I don’t think I would have a DomainModel base class at all. If that is what you were asking. In one of my apps I have a GameDomainModel and a PersonDomainModel. From a domain perspective they really don’t share much in common and hence I don’t have an AbstractDomainModel.

I sometimes use the prefix DomainModelValueObject for value objects but it’s more of a documentation thing. There is really not much difference between domain entities and value objects once you get past the identifier. So I tend to just call them DomainModels. I stay away from the term Entity just because it is confusing.

Be aware the DDD can be a huge time sink. Plenty of opinions on the “right” way of doing things. Make sure you actually have some worthwhile business logic before going too far.

I do like to keep model objects in one layer and the persistence functionality in another layer. That lets me switch between Doctrine ORM repositories and InMemory repositories. But my models are still mostly dumb objects with most of the business logic in services. Which is not DDD.

Well a domain model base class definitely can help in many cases, I’ve read Martin Fowler and Matt Zandstra’s books on the data mapper pattern and both have domain model base class implemented. It provides not only some common business logic, but also convenience for type hinting as a super class.

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?

If I recall correctly, and just in case this distinction matters, the mapper classes have a base class, but the domain objects do not.

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.

And I know you have this thing about have base classes. It’s just something you need to get over. Make some models in javascript. Prototype inheritance can be quite an eye opener.

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.