DDD Class that doesn't have an identity but can't be ValueObject because needs to mutate (change)

Question

this question has a little background here....

DDD class design dilemma with Value Objects with DB id and Entities

Since nobody gave me a convincing answer to my question, i am going to rephrase my question and give the people who answered the benefit of the doubt. Maybe i didn't present my question right.

I am assuming at this point you read my initial question.

So, ContactInfo doesn't need to have an domain identity, because belongs to User. It "can't exist" without user. It's nothing but a class (nhibernate component) wrapping other classes and collections (coming from a db), so, making it immutable would just be a nightmare if i wanted to replace it for a new instance. I would need to create a whole constructor with n number of parameters, and recreate the whole object graph, just because i wanted to update one street in the address collection. To my eyes, stupid.

What in the world is ContactInfo then? A mutable ValueObject? I am pretty sure Evan, the DDD guru, has a google alert for "mutable valueobject" and an exorcist at hand to send everytime these two terms come along.

I am very confused about this. Pretty much stuck because i don't want to be the "f... it" kinda a programmer and just make ContactInfo mutable just because (but at this point i have no choice). So, before i ended up having my own interpretation (and implementation) of DDD's concepts, i would like to have some opinions.

PS: I know this may come across rude but Please, no more copy and paste answers from Evan's book. Neither abstract concepts. We all know about Order and Orderline, we all know about struct and reference types, Blog, Post and Comments. This is a specific scenario with everything you need to know about this problem... so i would really appreciate a specific answer to this scenario.

Thanks :)

Answer 1

1. The "can't exist without" rule mostly applies to sub-entities of a Root, not necessarily Value Objects. I wouldn't be shocked to see a ContactInfo Entity with immutable value objects in it, as long as it is not an aggregate root.

2. Now if you really want ContactInfo to be an immutable value object from head to toe and don't want the pain of re-instantiating a 95%-similar object, you could create a Builder variant to generate a slightly different instance from an existing one in a short, elegant way. Something like ContactInfo.BuildFrom(oldContactInfo).WithPrimaryAddress(newPrimaryAddress).

Anyway, my advice would be to go for one solution and not get stuck in analysis paralysis. Correct me if I'm wrong but I doubt these classes are a critical part of your system, so you can always refactor them later with minimal impact.