Understanding Entity and Value Object Concepts in Message Domain Design

Scenario: User A sends a message to User B, and B replies. The current design treats the message as an entity (aggregate root) while the sender and recipient are modeled 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 by its identity and continuity , not merely by its attributes.

Many objects are not defined by their properties but by a series of continuity and identity.

Identity in an entity is unique and immutable . The article uses the twin‑brother analogy: a necklace that uniquely identifies each twin, remaining unchanged throughout their lives, illustrates identity.

Continuity refers to the entity’s persistence across its lifecycle. The necklace that stays with the twin throughout growth demonstrates continuity: the identifier remains constant while the entity evolves.

Another excerpt from DDD states: an object that maintains continuity independent of its attributes throughout its lifecycle is an entity.

Thus, an entity’s essential traits are:

Identity (uniqueness, immutability)

Continuity (persistent existence across time)

2. How is the Message entity derived?

Applying the two traits:

Identity: Messages must be distinguished by a unique, immutable identifier (e.g., GUID). Titles or content alone cannot guarantee uniqueness.

Continuity: A message’s lifecycle—from creation, through processing, to eventual deletion—must be traceable via its identifier, ensuring consistent handling across stages.

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

3. Why are sender and recipient not entities?

The article discusses a previous view that contacts are value objects because they are fetched externally and attached to a message without independent storage. However, contacts also possess identity (unique IDs) and continuity (their existence is tied to the message lifecycle), suggesting they could be entities.

Designing contacts as value objects simplifies some aspects (e.g., no separate management), but it limits functionality such as implementing user‑level features (e.g., mute). Recognizing contacts as entities provides clearer semantics and extensibility.

Conclusion

In the messaging domain, both Message and Contact should be modeled as entities, while auxiliary concepts like MessageState and MessageType remain value objects.

Recommended reading links are provided for further exploration of architecture principles and related case studies.