According to Eric’s definition of entities: “An object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity”

Does that mean apart from all the attributes every entity should also have some sort of status enumeration in them?

e.g. Order entity going to have OrderStatus, Task entity going to have TaskStatus, RequestForm entity going to have ApplicationStatus, etc

Does it mean every entity should have some sort of enumeration (point to the current state of the entity in the lifecycle) in them?

If not then how we are going to know at which stage the entity is in?

Edit: I said Enumeration as an example. It could be a string, Int, multiple boolean etc.

Edit: Further clarification to my previous edit. I meant, to keep track of the entity’s lifecycle it could be any other variable of type string, Int, multiple boolean, enum etc.


I think this can be answered by counter-example, specifically in many applications created using DDD a person/customer would be considered an Entity.

I can see how your business requirements may lead you to associating a state to a Customer (Prospect, Quoted, Signed, …), however you could also say that such statuses are more appropriately applied to an Order (typically associated with the customer). Therefore I think it is quite likely that a customer may not have a state that changes over time (at least some business requirements may not require such a state). If Customer isn’t a good example, you can probably find a different Entity such as Address that may not have a changing state that needs to be represented as an Enum.

If not then how we are going to know at which stage the entity is in?

Okay, so lets refine your question to Entities that have a clearly enumerable set of states – it may make sense to represent this as a enumeration, or under closer inspection you may choose a different representation, for example a set of boolean flags (with checks to ensure only valid combinations are allowed).

Another possibility, may be that the current state of an entity is the status an associated Event entity – or perhaps there is more detailed logic that only certain states correspond to events – in short the representation does not require a simple enum.


That’s not what “continuity” is about here. The point is that an object can be distinguished from another object, even if their domain attributes are identical, when this is necessary.

For instance, if your objects model taxi cabs, they will pick up and drop passengers over and over, essentially having only two different states. For normal purposes (ordering a cab) it’s enough to know their attributes to decide which taxi to send (speed, model, capacity etc.). But if a customer turns up saying “I lost my important briefcase in the taxi that brought me to the airport yesterday”, it’s not enough to know that it was a Sedan; you have to know which specific Sedan in your fleet took the job.

A class that allows this kind of distinction supports “identity” in the sense of the quote.