Domain-Driven Design
Entities
Things with identity that can change over time and still be the same thing.
An entity is something the model follows over time. Its identifier preserves that continuity while its other values change. Two in-memory objects may still compare as different objects. Domain identity and programming-language equality are separate rules.
The id is the sameness
A buying campaign remains the same campaign when somebody corrects its name. CampaignId stays; Name is replaced through behaviour that protects the naming rule:
public void UpdateName(string newName)
{
if (string.IsNullOrWhiteSpace(newName))
throw new DomainArgumentException(
nameof(newName), "Campaign name cannot be empty.");
Name = newName.Trim();
}
Changing the name does not create another campaign. Creating a new CampaignId would.
This is a model rule, not a claim about C# references. The campaign class does not override Equals. Two instances loaded with the same id may compare as unequal in C# while still representing the same campaign in the domain. If code needs identity-based equality, it has to implement that deliberately.
Matching data is not identity
Two draft campaigns can have the same name, dates, and budget. They remain different campaigns when their ids differ. Equality of the remaining fields does not merge their histories.
Identity belongs to a model
Catalog Creative and canvas Creative use different id types. They can both be called Creative without becoming the same entity. Bounded Contexts explains why: a canvas design becomes a new catalog item through translation. It does not age into the other model.
Typed ids make accidental comparison harder, but the wrapper is still only a value. The entity is the thing whose history the id identifies.
An entity’s attributes and measurements are often values rather than identities of their own. That distinction is Value Objects.