CODEWITHSUNDEEP
domain-driven-designvalue-objects
Dominik
Dominik

Reputation: 599

Having id-field on a value object in DDD

I'm working on a project where I had a value object (called SkillProfile) within an aggregate. Aggregate root is the User entity and the User has a unidirectional one-to-one association to it's SkillProfile. There is use case in the business where a SkillProfile can be shared with another User, but always as a copy (so modifying one of the profile won't change any of the other users profile). So far so good.

Now the business has the new requirement that it should be possible to see in reports which users share the same skill profile. This requirement cannot be fulfilled by the equals method on the skill profile, since there are skill profiles which coincidentally have the same values but weren't "shared" in terms of explicitly doing it. Of course the old requirement that skill profiles have to be immutable is still valid.

So here my question: Is it a good idea to invent a new field "Id" or "SharingCode" on the SkillProfile class and therefore give it some sort of identity although it's still a value object and not an entity since it has no state or lifecycle?

Upvotes: 3

Views: 1797

Answers (1)

theDmi
theDmi

Reputation: 18034

First,

so modifying one of the profile won't change any of the other users profile

If SkillProfile is indeed a value object, there should be no possibility to modify one! Replacing it within the User is fine of course. (just to have this clear before discussing your question)

With the new requirements, SkillProfile needs an identity - whether explicit or implicit - because it can no longer be compared by just looking at its value. Thus, it is now an entity.

Note that you don't need to treat it much differently than you were the value object before - it's a good idea to keep the entity immutable, for example, because this is still in the nature of the concept. So it shouldn't be a big step to make it an entity.

Upvotes: 3

Related Questions