Shouldn’t Location be a Value Object?

Eric Evan’s DDD book, Cargo Shipping Example, pg. 168:

Location

Two places with the same name are not the same. Latitude and longitude
could provide a unique key, but probably not a very practical one,
since those measurements are not of interest to most purposes of this
system and they would be fairly complicated. More likely, the Location
will be part of a geographical model of some kind that will relate
places according to shipping lanes and other domain-specific concerns.
So an arbitrary, internal, automatically generated identifier will
suffice.

Reason why author made Location an entity is because two different places could have the same name. But since it appears that Location is immutable and thus won’t change over time, wouldn’t it be better if it was instead a Value Object? Thus:

a) Why couldn’t we ( instead of automatically generated identifier ) introduce an additional attribute describing an actual charasteristic of a location, which would help distinguish between the two places with the same name? Then we could make Location a VO.

b) Even if we don’t introduce an additional attribute describing an actual characteristic of a location, but instead we use an automatically generated identifier, couldn’t we still consider Location as a VO, since the fact still remains that it is immutable and that application would work the same even if it tracked several instances representing the same Location?

c) From the quote it seems that author would designate Location as an entity even if instead of automatically generated identifier we’d use latitude and longitude to help distinguish between different locations. Why?

Thanks

I believe your fundamental premise regarding location being immutable is wrong and that’s what is hanging up your analysis.

Location is anything but immutable except for fixed, historical points in time. Good design encapsulates the areas that can change, so I can see where location should be its own entity instead of a simple value.

Sticking with the cargo container domain, let’s look at some examples to show how location is very much mutable.

Shipper The shipping company will generally have a fixed location over a period of time, but businesses can and do move their location. The relative size of what they ship presents the largest hurdle here for moving the business. But a company that deals in small goods with a low inventory can easily hop from one warehouse to the next.
Shipping container By definition of the domain, the shipping container is going to be moving from one location to another. From the source facility to transit to the receiving company, the container’s location is volatile.
Shipped goods present a similar challenge to the container, but the container will likely contain N amount of shipped goods. While you could assign the container’s location to the goods, it makes more sense to indicate the goods are located within a container. Using a value based mechanism only here will create convoluted code for tracking the location of the goods.
Receiver has similar challenges as the shipping company. Another consideration is what about tracking goods on a large property? Large goods stored on tremendously large lots are frequently moved around in order to support incoming and outgoing requests. Likewise, with small goods you may have several categories of small goods located on one shelf. Using a fixed value, how do you differentiate what goods are on the top shelf versus the bottom shelf? GPS + altitude are insufficiently precise to specify this sort of a location. Also note that I’ve created a de facto entity with my “solution” of combining GPS & altitude.

To summarize:

The chosen location value may be insufficiently precise to identify and isolate two objects in proximity to each other.
Location is mutable, it is going to change over time.

So let’s contrast location with an address.

An address is immutable as it belongs to a fixed geographic space and has an implied degree of precision (which may or may not be sufficient). Address is a property of a section of real estate. In the extreme and somewhat absurd example of moving a building (think big crane and heavy duty flatbed trailers) to another location, the addresses involved have not changed. The building does not carry its old address with it to a new real estate site, rather the building is given the address of the new real estate site. Whatever is built at the old real estate site receives the old address for its identification.

Part of the challenge here is the linguistic connotations of address and location. Many times they can be used synonymously, but in some cases they absolutely cannot.

A house has an address which is also a location that is for most intents and purposes fixed. You could say “the house’s location” and most would infer you meant the address.
An mp3 player has a location which may correspond to an address but there is no implication of being fixed or immutable. You can pick up an mp3 player and walk next door thereby change the location and therefore address. You cannot say “the mp3 player’s address” as it’s just nonsensical due to the implied connotations of the term.

When to use address versus location depends upon the stability of the object you’re referring to. A business generally is described as having an address but in reality it’s a location since it can and does change. Goods and containers have locations as they are prone to moving around.

The most defining characteristic between an entity and a value object is not if is immutable or not. You should look at the identity of the concept.
A location is a location despite his name change? Yes.

For example, you have a leg that ends on Taunton, England. In your system there is an object with description “Taunton, England” and country England. Meanwhile the village of Taunton declares his independence from England and now calls themselves Nuevo Toledo. In your system the description is “Nuevo Toledo” and the country is Nuevo Toledo. The location is the same as before? Yes, you still have to leave London by the M-4 and drive 40 miles.

The location has an identity that goes over the changes it has. The value of his atributes dont make his identity. Therefore it is an entity.

You can have value objects that are not immutable, too.

Filed under: softwareengineering - @ 07:42

Thẻ: domain-driven-design, value-object

Thiết kế website giá rẻ

Danh mục

Shouldn’t Location be a Value Object?