Understanding Entity and Value Object Characteristics in Domain‑Driven Design: The Message Example
The article explains the core traits of entities—identity and continuity—through domain‑driven design examples, demonstrates why a Message should be modeled as an entity, and discusses the reasoning behind treating Sender and Recipient as value objects or entities in a messaging domain.
The article explores Domain‑Driven Design (DDD) concepts of entity and value object using a messaging scenario where a Message is considered an entity and the participants (sender, recipient) are examined as value objects.
1. What is the most important characteristic of an entity?
According to DDD Chapter 5.2, an entity is defined by its identity and continuity . The author uses the analogy of twins distinguished by a unique necklace to illustrate that an entity must have a unique, immutable identifier that persists throughout its lifecycle.
"Many objects are defined not by their attributes but by a series of continuity and identity."
The discussion emphasizes that identity is unique and immutable, while continuity reflects the entity’s persistent existence over time.
2. How is the Message entity derived?
Applying the two entity traits:
Identity: A message must be distinguished by a unique, immutable identifier (e.g., GUID) because titles or content alone cannot guarantee uniqueness.
Continuity: The message’s lifecycle—from creation, through processing, to deletion—demonstrates continuity. The identifier is used at each processing stage to refer to the same message.
Therefore, a Message satisfies both entity characteristics and can be modeled as an entity.
3. Why are Sender and Recipient not entities?
The author initially treated contacts as value objects because they are obtained from external sources and only needed as values (e.g., SenderID, RecipientID) within the message context. However, the analysis shows:
Identity: Contacts do have unique identifiers, but these identifiers are only relevant when attached to a specific message.
Continuity: Their continuity is dependent on the Message entity; they do not possess an independent lifecycle within the messaging domain.
Thus, while contacts have identifiers, they are considered value objects because their existence and behavior are scoped to the Message aggregate.
4. Should Sender and Recipient be entities or value objects?
The conclusion is that both Sender and Recipient (collectively “Contact”) should be modeled as entities alongside the Message entity, with additional value objects such as MessageState and MessageType supporting the aggregate.
Author: 田园里的蟋蟀
Source: cnblogs.com/xishuai/p/ddd-entity-value-object.htmlOverall, the article provides a practical DDD analysis of entity vs. value object decisions in a messaging domain.
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.