3

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?

Dominik
  • 599
  • 1
  • 4
  • 18
  • 2
    I think what you are talking about is no longer a value object. If it must be identifiable, then it is an entity. Another option could be to use the aggregate (user) id, to identify the origin of the skill profile, but I don't understand your domain in depth, so I am not sure whether it could work. – inf3rno Nov 22 '15 at 13:43

1 Answers1

3

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.

theDmi
  • 17,546
  • 6
  • 71
  • 138
  • You're right, modifying is the wrong term. What i actually meant with modifying was changing the `User`s `SkillProfile` property. Of course this will be done by replacing the old value object with a new one. I agree with changed SkillProfile from value object to an entity. Now the Aggregate Root has to ensure the skill profile will be replaced with a new identity. – Dominik Nov 24 '15 at 07:11
  • @Dominik The changes of the business requirements can cause changes in the domain model. There is nothing wrong with that... – inf3rno Nov 28 '15 at 21:20