I don't really quantify an entity as something is necessarily persisted to "durable storage". Eventually you have to save something, and usually when an application starts up or a user requests something it must load. I can buy that, but I don't equate entity to persistable entity. I generally want to model my domain as I need it to be as it will solve some business problem.

The idea of saving/loading data is not a business problem (although I get BAs telling me it is). It's an infrastructure problem. I see entities as the lego blocks that make up the heart of the software. The need for persistance is more like the veins and arteries that carry the blood of the system to that durable storage you mention.

As for "business objects" they tend to be used interchangabley but then I've seen people use Value Object and DTO the same way, or Repository and DAO but they're not. If I was talking to a business user, I might use the term business object so they didn't look at me like I had 3 heads when I said "and the entity will validate itself before we save your information".

My understanding of term Entity is influenced by Eric Evans (DDD). I contrast it to a Value Object. An Entity has a meaningful identity, whereas a Value Object does not. Whether or not something is an Entity can depend largely on the context of the problem domain.

Examples of an Entity might be Person, where every instance of Person has a meaningful identity. Whereas Color would be a Value Object, and even though you might have 1,000 instances of Color with a value of yellow there is no meaningful distinction between those instances.

Having said that, Business Objects is a generic term to me that just means The Domain Model (which might include things other that Entities, and Value Objects, such as Services).

That's my two cents for the moment. The problem with this whole Continuous Learning bit is that my understanding will probably be different in 3 months. :-)

yes, i have to agree with Christopher on this one..although I too am heavily influenced by Eric Evan's DDD..

Entities have identity (Customer, Order, Product)

Value Objects dont (ie.. Money, Country, Language)

A very key aspect of my entities is that they have behavior (OOP). Behavior is what seperates my entity from my DTO. The DTO only has data. This is in direct constrast to MS's definition of Entity, which is really a DTO.

I left a fairly long comment here on the same topic.

http://codebetter.com/blogs/scott.bellware/archive/2007/04/09/161490.aspx#comments

Let me say I HIGHLY HIGHLY HIGHLY recommend reading DDD. The original book was a HUGE eye opener for me.

Just to be clear, if you have two money objects with the same amount (say $3), you really dont care which one you are referencing (think flyweight)...

If you had 2 orders with the same line items and same customer, you had better care which is which (the orders have identity--OrderNumber). This is an easy way to think of the two.

As for Business Objects, the definition is murky for me since I haven't read Rocky's book (of the same name), but I would guess that a Business Object is just a generic reference to objects in the domain model.

http://channel9.msdn.com/ShowPost.aspx?PostID=169693

A 3rd definition can be found if you talk to data modelers. Their ER diagrams have entities but really are "data entities" inside the database (which leads us into the OOP/Relational mismatch). Some people (like MS) bring those "data entities" into their app and call them entities, but again, behavior is one of the key diffferentiating characteristics (and now we are back to DTOs).

Evan

I would have to agree with the other commenters so far. Business Object and Domain Object have the same meaning for me. It's a generic term that refers to every object that is not part of infrastructure or UI (or other boundary).

An Entity is any Domain Object with Identity, as Chris mentioned above. Person, Order, Company, etc. It is irrelevant whether it is persisted or not. Value Objects are Domain Objects without Identity. Colours, Money, Widgets, etc. Everything else is a Service, whether they be repositories, utility classes, etc.

At least that's how I think about these things...

Ayende,

I can only guess that this post was partially inspired by the recent .NET Rocks episode on the Entity Framework. As for myself, ever since I listened to that episode I have been pondering this issue because I was greatly disturbed by the hosts' comments, but not as disturbed as I was by the MS rep's comments. To me, it seemed like they were all confused about what an entity is...and then I thought to myself "If they don't know what an entity is, how can they build an Entity Framework?" Personally, I agree with all the posters above as to the meaning of these terms. I derive most of my understanding from Eric Evans, who I believe has written one of the best books on software development, period. I'd like to see every developer on the Entity Framework team stop what they are doing, go read DDD (and possibly Nilsson's book as well) and then when they have a thorough understanding of the problem domain, go back to work on the framework.

I tend to think of Entities as objects that map to database tables. So I guess from that standpoint, I'm in the corner that says "persistent storage" is part of the definition of an "entity".

Business Objects, to me, have a different meaning. They're not just data; they're behavior and functionality (and by functionality I mean things like databinding and property change notification, which become concerns that are handled by the business object hierarchy).

I separate these two terms by thinking about the wire. To me, a business object is something that resides on the client side of the wire and is useful to the client application. An entity is something that resides on the server side and is related to the database/persistent storage. Now, they could conceivably be the same class, and you can throw in O/R mapping to blend the two things together. But conceptually I still look at them as two things, each on opposite ends of the fence, so to speak.

Just my 2 cents.

I recently posted on this subject. You can find it here.

http://www.lostechies.com/blogs/joe_ocampo/archive/2007/04/14/a-discussion-on-domain-driven-design-entities.aspx