Why is the product of the order item a reference to the ID of the product and not a value object?

Question

I am seeing this example in the Microsoft documentation:

Here we can see how OrderItem has a reference to the ID of the product, it is the first option that sure people uses to think, me too.

But I was thinking about this and I was thinking, why isn't OrderItem a value object?

If I use the ID of the product, I have the problem that if after I accepted the order and the description of the product is changed, I will see the new description. So if I want to keep the description that it had when I accepted the order, I can't do in this way.

So I was thinking that perhaps in this case it would be better a value object product, that it will have three properties reference, description and provider. I don't need more for an order item. In this way, the information will be store in a columns of the order line table, and then I will can prevent to modify it if the order is accepted.

Perhaps the example is simply to try to be more clear, but really all the examples that I have seen about order and items are in this way, to use the ID of the product.

So in summary, what are the advantages to use the ID and what are the advantages of the value object?

Answer 1

What you're after is called immutability. Value objects do not have a monopoly on immutability. Sometimes things are immutable by policy. For example:

OrderItem.Price 

Now sure Product.Price might change. But here sits OrderItem.Price saying we don't care because the price for this particular order was set when it was ordered.

You might notice there's also a ... below price saying you can nail down other fields like that as well. Just because you have a link to the current product info doesn't mean everything is editable. We can simply remember what it was when it was ordered and know that's what's legally binding.

Yes you can insist on making a value object out of it to enforce immutability. But if you can enforce some simple policy rules you can do it this way as well.

So many cats to skin. So little time.

Answer 2

The simple answer is that a Product is generally too complex an object to represent as a value.

Not sure what you mean by reference. Obviously you wont have a ProductId anymore if its a value object.

Description is subject to arbitrary change, spelling mistakes, corrections, multiple languages etc. Also you will have different products with the same description. ie different models or manufacturers or years of manufacture etc

Provider, only some combinations of product and provider are going to be valid. how are you going to know which?

Then we are going to have a whole bunch of other data, you probably have either a sub or over product to represent multiple colours of the same item, sizes, base price, stock levels, tags for searching, pictures etc etc

Value types work for things which generally only need a single field to completely define them. Dates, colours etc

Answer 3

A value object doesn't prevent someone from modifying the database — what if someone changes an Order or OrderItem?

Well, you say, that would be silly, we need to have some discipline around changing things arbitrarily.

Having a discipline or protocol around how the data is used is important.  Changes should be allowed to existing products in the database only if they are meant to supersede/correct old information.  A new version of a product should probably get its own new product id.  Products that are discontinued should be marked that way and remain in the product table rather than begin deleted, which would make it impossible to view older orders.

So, as some discipline is required in all cases, why not have a sensible one around product management?

Capturing additional information in the OrderItem won't necessarily hurt, but moving to a value object — removing the product ID from the OrderItem — would be error prone and inefficient.

You're also showing that your view of the world is purchasing, ordering and customer relations, while someone else controls products — meaning you feel that you cannot rely on them, for example, to have any discipline about deleting product id's that you need for OrderItems.  You should make your requirements known to the other responsible parties in the company — that you need stable product id's and descriptions.