Business objects vs. entities

In my experience entities are usually associated with CRUD. Business objects can also be non persistent objects such as strategies, policies etc.


All entities are business objects, but not all business objects are entities.

Entities are business objects whose identity is defined not by their attributes, but by an identifier, like Product's ID.

An example of a business object that is not an entity could be Color. Color derives its identity from its RBG values.

I'm referring to, of course, Entities and Value Objects in Domain-Driven Design.


I consider them the same, although maybe if you have some controller-like classes (which operate on your domain model) in your business layer they might not be called entities. I would say that classes like Product are both business objects and entities, while a ProductController would be only a business object. An entity represents a domain model object - a user, a book, a car, etc., something that contains data of its own as well. I think it's just a matter of naming and is not important, I tend to use both terms interchangeably, but will usually use the "rules" I depicted above.


I would call it a DTO (Data Transfer Object). I have also seen them called "Property Classes" in times past. I would NOT call it a Business Object because it has no behavior and by definition BO's are defined by their behavior.

Tags:

Oop