I have been working on a little project in DDD. I see everywhere that Value Objects are immutable, thus, you can’t modify it. Only entities.
I am going to use the example everybody uses. Address. Let’s say Address is a VO of the Customer entity (which is a root aggregate as well). If the user updates his Address, which is valid in any shopping cart scenario, then what am i supposed to do? I have to modify that VO address in order for me to persist it into the database. Meaning, this VO must have an identity somehow in order for me to identify it in the database. Unless NHibernate takes care of it using mapping, right. That’s not the case with LinqToSql thou.
Or I guess i have to create a new Aggregate where Address is an entity instead? Then almost having a copy of Address everywhere i need Address in my aggregates?
However. I still can’t wrap the whole Entity/VO concept. Seems to me like everything that has a representation on the DB, even thou you use it as a VO in your Model, it’s somehow an entity because in order for you to persist it, you need some sort of KEY to identify it in the database.
At the end of the day, all Value Objects’s data come from a database (mostly). So i still can’t understand how you must make them immutable in case of updates in that data.
After two months of intense reading, i find the whole DDD a huge contradiction issue. Read all those blogs and you will see what i am talking about. Unfortunately there is ZERO demo applications out there that you can use as a role model or guidance. They all are pretty much influenced by the developer’s preferences. Then they end up attacking each other’s blog. Overnight-DDD-Guru’s blogs are really helping to the confusion of the whole community.
Thank you for stopping by. Looking forward for a constructive discussion.
I believe your confusion lies in the artificial coupling between database row identity and the notion of identity associated with an entity in DDD. They are certainly related because an entity will have a corresponding identity represented in the database as an identity column. However, just because something has an identity as a database row it doesn’t mean that the object has identity in the DDD sense.
In you address example, the value comprising the address VO would typically be stored in the same row as the customer entity. In this way, the address is a value object because it isn’t stored in a row of its own and has no identity. When you update an address, you alter the value of the address property on the customer entity, which in turn reflects in the database row.
There are cases where a value object would be stored in its own row. For example, in the stereotypical sales order model, an order is an entity (aggregate root) and line items are value objects. While line items are VOs, in the relational model, they are stored in their own table and may very well have primary keys. In the domain model however, the VOs are tied to the order entity and don’t have identity outside of that entity.