Takes on this anyone?

I follow I think.

So what your’re saying is that when dealing with value objects with changes, it doesn’t change the value object but any/all related entities since the value objects are just a subset of information that is normally housed within an entity.

If I am heading down the right path here, then can all value objects be treated in this manner?

I have another question about implementation details of a value object. On my group posting, let’s say I have “States” value objects that relate to states in the US. When I want to retrieve a list of states to display to the user would this information be accessed through the aggregate root or via a custom query that would return only these lookup values. Little off topic but this also got me thinking.

Sean you are right that you have to know the context of the object in order to truly understand if it is a value object.

For instance:

Lets say that you have a Person object that contains an Address object that maps to an address table. The Person object acts as the aggregate root and has global domain identity (their name) within the family context. The address identity has local identity within the Person aggregate and the client has know knowledge of the ID field that is used to persist it. Just the repository for the person aggregate.

remember that value objects are immutable, so you don’t care what happens to them, where Entities are not and any change in them causes them to be in transient state.

Using the example above. The address class on its own does not have any meaning to me without its container in this case the person object. On its own I should never care if the address object changes. In fact it should not have a repository class. How ever if the address belongs to a Person and the address changes then it places the person in a transient state. Make sense?

That is actually a good question.

I would imagine at first glance you wouldn’t be able to tell without knowing the context of the objects.

Perhaps Joe can shed some light on this.

Domain identity should not be confused with system identity. System identity is often need when the repository has to persist the entities to a relational database. At that time properties or private fields have to be created in order to persist entities and value objects.

But lets say your repository were serializing to an XML file. You wouldn’t have this issue.

The key here is not to make it more complicated then it needs to be focus on the Domain first from a Domain Context use the Domain Identities as lookup values.

Using the car analogy again. The car has global identity its VIN within my domain because me as the customer that is what matters most to me. Within the car however the factory saw fit to Give the engine block a LOCAL identity within the car. But to me as the consumer I can care less.

Does this make sense?