Understanding Entities and Value Objects in Domain‑Driven Design: Why a Message Should Be an Entity and Contacts Should Be Treated as Entities

Message scenario: User A sends a message to User B, and User B replies to User A.

Current design treats the message as an entity and the sender/recipient as value objects.

1. What is the most important characteristic of an entity?

According to Domain‑Driven Design (Chapter 5.2), an object is defined not by its attributes but by its identity and continuity .

Many objects are defined by a series of continuity and identity rather than by their properties.

Thus the two essential traits are:

Identity (uniqueness and immutability)

Continuity (the object persists through its lifecycle while remaining identifiable)

The article uses the analogy of twins wearing distinct necklaces to illustrate identity (the necklace uniquely marks each twin) and continuity (the necklace stays with the twin throughout life).

The key difference between an entity and a value object is that an entity must answer both “what is it?” and “which one is it?” whereas a value object only needs to answer “what is it?”.

2. How does the Message entity arise?

Applying the two traits:

Identity: Messages must be distinguished by a unique, immutable identifier (e.g., a GUID), because titles or content can be identical yet represent different messages.

Continuity: Throughout its lifecycle—from creation, processing, to deletion—a message is tracked by its identifier, ensuring continuity.

Since Message satisfies both identity and continuity, it is appropriate to model it as an entity.

3. Why are the sender and recipient not entities?

A previous discussion questioned treating contacts as value objects. The article revisits this by examining the same two traits for contacts:

Identity: Contacts need a unique, immutable identifier (e.g., SenderID, RecipientID) to be distinguished within the messaging system.

Continuity: A contact’s continuity is tied to the message entity; it does not exist independently in the messaging domain, but its identifier is required whenever the message is processed.

Although contacts are fetched from an external store and depend on the message, the article argues that because they possess both identity and continuity (albeit dependent), they should be modeled as entities rather than pure value objects.

4. Should sender and recipient be value objects or entities?

Conclusion: Sender and recipient (collectively “Contact”) should be designed as entities.

Resulting model for the messaging domain:

Message entity and Contact entity.

Various value objects such as MessageState, MessageType, etc.

Related reading links (original Chinese titles) are provided at the end of the article.