2

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.

Pepito Fernandez
  • 2,352
  • 6
  • 32
  • 47
  • ALWAYS separate the domain from the database. When doing DDD forget completely that you have a DB. Nhib, L2S etc they don't matter. What about the app will store everything in the cloud? – MikeSW Nov 17 '12 at 10:52
  • Cloud is nothing but a remote server/service. I don't know why the whole fuzz about the Cloud nowadays. Yahoo, in 1990s, was an email app in the "clouds". If you had a FTP site, and a local FTP client, that's an antique representation of Google Drive, or Dropbox these days. – Pepito Fernandez Nov 20 '12 at 19:01
  • I forgot to answer your question. You just don't store in the cloud. You have to store somewhere in that cloud, let's say, a sql server masked as Data Server in The Clouds (for marketing purposes). – Pepito Fernandez Nov 20 '12 at 19:02
  • Azure Storage for example is not quite SqlServer and you won't be able to use an ORM. Also, what about NOSQl. I've mentioned cloud as an example (it's trendy right now) the point is that the Persistence is outside the Domain and the storage system can be anything and it's a detail of Persistence, so don't mix together those two. – MikeSW Nov 20 '12 at 19:10
  • Mike, first of all, thank you for following up. Really appreciate it. My point is that i find so much contradictions in this "way of thinking/coding". Take a look at my comment on @eulerfx's answer. – Pepito Fernandez Nov 20 '12 at 19:15

4 Answers4

9

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.

eulerfx
  • 36,769
  • 7
  • 61
  • 83
  • 1
    So, let's say for the sake of an example, that i have multiple addresses for one user. The user register but of course, he hasn't entered any address yet. Then once the user is registered (user record already exist in DB) i want to add one address for him. That means that i have to modify the Addresses[] (a collection of Address VO) by adding a method AddAddress( what comes here? An instance of Address? a factory method for Address? string values for street, city, etc? Then i am violating the Not Modify VOs. ???? What to do? What to do? Eric's book is so abstract that i can do whatever i want – Pepito Fernandez Nov 20 '12 at 19:12
  • 2
    The `AddAddress` method could either an instance of an `Address` value as an argument or a set of arguments (string values) that can be used to create an instance of an `Address` VO. This can go either way because an address is a VO, which means it is just like a `string` or an `int` value in this sense. You're not violating the immutability of the Address VO because the Customer is the entity. You're not changing a given `Address` value, your changing what the `Customer` entity references. Just like if you change the customer's age. You're not altering the value of the prior date value... – eulerfx Nov 20 '12 at 19:38
  • 1
    ...you're altering the age value associated with a given customer entity. – eulerfx Nov 20 '12 at 19:38
  • That's a good answer indeed. Now, following your logic, in case i do have, let's say, two addresses and i would like to update one of them, let's say, correct zip code, (remember both addresses are already in DB), would you have a repository method to UpdateAddress(int id //db id). Repopulate Addresses after that? Have a aggregate method to UpdateAddress(which one? is a value object, so no ID). How do you deal with updates of VO? – Pepito Fernandez Nov 20 '12 at 20:16
  • 1
    To update a VO you simply replace the value all together. For example, to correct the zip code of an existing address, create a new instance of an address and replace the existing instance. You could have a method on the address VO which returns a new address instance with specified corrections. – eulerfx Nov 20 '12 at 20:19
  • http://stochastyk.blogspot.com/2008/05/value-objects-in-domain-driven-design.html seems like i was reading the exact same thing when you were posting this. Check this out by the end of the article. – Pepito Fernandez Nov 20 '12 at 20:23
3

Actually, there's PLENTY of demos around, probably in every technology you imagine, starting with original DDDSample in Java. There are at least two ports of this sample to .NET: NDDD and DDDSample.Net.

As for VOs and persistence, if you think of a VO as an object wrapping few columns from a table representing an entity than it is easy (e.g. Money VO wrapping amount and currency). The problem starts when you want to normalize the data on SQL level and create a table for VOs (instead of embedding them in the entity tables). I don't know the good solution for the problem but fortunately it is not a good practice when implementing DDD with relational storage. Why? One of the most important principles is that aggregates should be as much independent of each other as possible. Sharing a VO class in object model is OK with this rule but sharing VO table in data storage is not, as this single table may become a locking bottleneck for example.

In short: when using SQL database to store domain model consider not normalizing the model between aggregates.

Szymon Pobiega
  • 3,358
  • 17
  • 18
  • :) I can see why you recommended those two. Yes, i actually took a look at NDDD and i found some violations according to Eric's Book. A Value object in Cargo aggregate has a member of HandlingType, a VO of Handlins aggregate. Isn't that a violation to "not access VO directly from other VO from a different aggregate"? maybe i am wrong, but that's what i interpreted from reading Eric's book. I am going to take a look at your DDDSample. I like the CQRS concept so that's an extra appealing for me. – Pepito Fernandez Nov 20 '12 at 19:06
  • So, in your second paragraph, you say that normalizing my database is a threat to an optimum domain modelling? That means duplicated data whenever it is necessary for the sake of the domain? What if two aggregates needs to access the same data, or let's say, two BC needs to access user data. Wouldn't that create a bottleneck as well? – Pepito Fernandez Nov 20 '12 at 19:30
  • Szymon, I was looking at your DDDSample (Vanilla). Why would you move your DTO and Facade to the presentation. Was it intended to get rid of the Remoting capabilities of NDDD? I see multiple solutions, i read your documentation. Which one should i use as a good guide? Thanks – Pepito Fernandez Nov 20 '12 at 22:35
2

You can also try to have a look at such problems from the real world (or domain) point of view. Addresses rarely change. It's more common that the customer changes his address (he's moving to another flat for instance) that the address itself is changed.

Having this in mind an address has to be a value object.

Rafał Wicha
  • 101
  • 2
  • 5
0

Hey I see this is a really old question, but I am on my DDD quest and have had some similar queries.

The best route to a solution I have found with DDD is to forget about the DB and think about the model. So in the situation above, where you have a Customer and an Address VO and you want a list of Addresses for a customer, say in the scenario of an Ecommerce site where the customers has multiple shipping addresses to choose from. Well, in the true context of the domain model, those addresses are not just Address VOs, they are CustomerShippingAddress entities.

So, your CustomerShippingAddress entity has an identity, and it has an Address VO. Maybe it has some other stuff like IsDefault, and DateAdded etc

I would suggest you can only instantiate a CustomerShippingAddress from the Customer entity passing in an Address VO, and you get back an Aggregate root of the CustomerShippingAddress which holds an ID reference to the customer.

This way you maintain your AddressVO, but can reuse that VO in multiple scenarios.

When a customer selects an Address as the shipping address for an order, the AddressVO they choose would be applied to the Order aggregate. This means the shipping address on that order is locked in time to the Address VO at that time. The CustomerShippingAddress may be modified later, but the shipping addressVO would remain the same on the Order for ever.

PaulAdvancedUk
  • 153
  • 2
  • 10