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


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?


  • 1
    I'm kind of suspecting this is going to be closed out as overly-specific. We're essentially discussing the merits of a specific textbook here, and even though I may have interest in the problem, I'd need more context from the book to come up with an explanation.
    – Katana314
    May 21, 2013 at 16:58
  • 1
    Typically x/y point coordinates are value types in all cases I've seen them. That doesn't mean you couldn't have a reference type encapsulating a name and a coord that's a value type May 21, 2013 at 17:01
  • @Katana314: The software should 1.track key handling of customer cargo 2. book cargo in advance and 3. send invoices to customers when cargo reaches some point in its handling. Other than that, another clue may be on pg. 172: "We also need to find a Location to specify as the destination for the Cargo, so we create a Location Repository." But I don't see the need for having to find a specific Location, since we could instead simply create an appropriate Location value object.
    – EdvRusj
    May 21, 2013 at 18:10
  • @EdvRusj: write that question as an e-mail to Mr. Evans, maybe you are lucky.
    – Andy
    May 22, 2013 at 21:05

2 Answers 2


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.

  • 1
    1.It's true that in the examples you provided locations of shipper,shipping container etc may change, but couldn't we argue that in fact old location was simply replaced by new location? For example, when Shipping company moves its business from location L1 to location L2, we could argue that L1 itself hasn't changed,but was instead replaced with L2? 2. "The chosen location value may be insufficiently precise to identify and isolate two objects in proximity to each other." Couldn't we simply introduce additional attributes that would help distinguish with greater precision different locations?
    – EdvRusj
    May 22, 2013 at 17:36
  • 1
    The example you provide on old | new location counters the presumption of immutable. Your question conjectures "XYZ is immutable, therefore it should be Value, right?" My answer was that "No, XYZ is not immutable and a simple Value may not be sufficient." Can you use a value? Sure. Is Value the apparent best choice because XYZ is immutable? Not really and that's a faulty assumption.
    – user53019
    May 22, 2013 at 18:09
  • I understand your point, but I read several posts on why Address should most of times be a VO and I find Address and Location very similar in terms of their usage, hence I'm having difficulty figuring out why one is best defined as VO and other as an entity. Does that make any sense :(?
    – EdvRusj
    May 22, 2013 at 19:33
  • 1
    @EdvRusj - yes, that makes quite a bit of sense and I understand the confusion now. Have a look over my revised answer to see if the distinction is more clear.
    – user53019
    May 22, 2013 at 20:23
  • 1
    @EdvRusj - that's a fairly decent analogy. I might say "applied" instead of "borrowed", but we're in the realm of splitting hairs. An address is an external or meta construct that facilitates the identification of a geographical point.
    – user53019
    May 22, 2013 at 23:56

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.