0

We have identified a Location entity in a database as a value object in our domain (DDD). Locations are used by other domain objects, but don't really "stand alone" -- they always belong to another entity.

Now we are trying to edit a list of these values in a simple MVC web application. So the view would show a list of locations in a view model LocationViewModel.

However, the value object is by definition immutable, yet does hold a reference to another entity (Business).

Domain:

public class Location : ValueObject<Location>
{
  readonly locationId;

  public int LocationId {get{return _locationId;}}
  public Business Business {get;set;}
}

My problem is understanding how you can simply edit a bunch of value objects in a UI and change, e.g. what Business the location belongs to. A value object is not supposed to have an "identity", but it does need an ID so the repository can update the database.

I also don't think you can make Location an entity just because you want to edit it in the UI. Or is Location, in this scenario indeed an Entity? What am I not understanding?

Thank you!

John
  • 3,591
  • 8
  • 44
  • 72
  • What is a location in your domain? How is it being used? How is it being shared? If a shared location values are changed, should the change be reflected in entities bound to the same location? – plalx Apr 16 '15 at 01:14
  • A location is a palce where you store and diaply items, like a shelf, or a display case. You can assign items to a location. So you can't delete a location if items are assigned to it. A location is also linked to a business and a physical address. I don't believe a location is "shared", it has its own set of tables that relate to other tables, e.g. business, item. – John Apr 16 '15 at 09:15
  • If you keep trying to focus on persistence concerns you will never understand DDD. Forget about database tables or any other persistence details. Think about how a `Location` is being used by other objects in your domain. What makes you think Location is a value object? – plalx Apr 16 '15 at 13:56

2 Answers2

0

It's a classic problem. In one context it's an entity and in another a value object. I found the example of a telephone number helpful to understanding this sort of problem.

In a CRM for example, a telephone number is a value object. The same one can be associated with multiple contacts. It varies by value (key concept here). So in this context it's a value object. In this example, I could store telephone numbers in the database and the 'ID' would be the telephone number itself. If the value object was made up of multiple parts then they would form a composite key.

If however we looked at a telephone number at a telephone company. That would most likely be an Entity. It could have all manor of information attached to it. All that info would vary by ID (which in this case would be the number).

In your case, Location sounds like a value object. If you need to save it in a database as a thing rather than just as part of an entity then use it's parts as a composite key. You will need to handle what happens when you 'change' one as it's not a change but the creation of new value object. One approach is to remove the old and insert the new. Or just keep all versions. It depends on your domain.

Hope that's helpful.

Codescribler
  • 2,235
  • 18
  • 22
  • @Codescibler thanks sir! So if I undertand this correctly, editing the value object all by itself is allowed? For that I do need to treat it as having an ID field, so that I can "find"/update/delete the changed record in the DB? When linked to another entity, then its immutability implies that when changing the value object I need to create an entirely new one. In the database, that would mean I get a lot of orphaned entries unless I remove the old record. – John Apr 15 '15 at 16:11
  • Not really - it's still immutable. Think 'string'. When you 'edit' a string, it's actually a new object. So 'editing' a value object in a db would be the same as delete followed by an insert. The 'ID' is the value. You wouldn't have a separate key on it. – Codescribler Apr 16 '15 at 13:55
0

You don't change a value object. You create a new one with different values. If the value object has few properties that you want often to change, some helper methods are usefull. myObject.WithX(4711) will create a new instance with all properties the same as myObject but the X Property changed to 4711 for example. To "edit" a value object in an UI you use a viewmodel. The Viewmodel is not a value object (and no entity by the way) and is not part of your domain. It's purely in the Presentation Layer. It is editable and mutable. It could have a constructor, taking your (immutable) value object to copy its values from and it could have a ToXXX Method to create a new (immutable) value object with its current (and changed) values. If you want to store your value objects in a separate table (instead of roll out the fields in the table that stores the owning entity) this is purely data access layer related and not part of your domain model. This could be done by mapping. In the value object the database id is immutable and has no meaning in the domain model.

Holger Thiemann
  • 1,042
  • 7
  • 17