Alberto gave you a good answer, but I'd like to add some remarks. The entity vs. value object distinction is really fundamental to the style of object programming championed by DDD. Most OO systems get into trouble because they go way too heavy on the entities and lack value objects altogether (the only traces of value objects they have are some enums here and there). This is an anti-pattern one might call the "anemic value object". :) In fact, what we usually want is the opposite: a lot of meaningful value objects and just a few entities. So for starters, as a rule of thumb, think "value object until proven otherwise". That's what I do. You're less likely to mistake something that ought to be an entity.

Secondly, apply the "water bottle test". This is an example that Eric uses in classes, where there's often a table stocked with bottles of water for the participants. He'll pick up two unopened bottles and ask someone, "Which of these do you want?" The answer, of course, is that it doesn't matter - they're interchangeable. Then he opens one of the bottles, takes a drink, and asks the same question again. Now the answer is, "I'll have /that/ one, please" - the one that he didn't drink from. Before the bottles have been drunk from, we can pass them around without caring which is which. Those are value obects. After they have been drunk from, we need to keep track of their individual identities because they differ in a way that matters to us. Those are entities. (One could make the example more complex by pointing out that it's really the owner's identity that matters here, not the bottle's... but never mind :))

Now let's look at your state example. Your question is a very good one. It seems like Florida should be a value object but on the other hand the state of Florida clearly has an ongoing identity. It goes through state changes (no pun intended!) over time. For example, in recent years it has acquired a number of electronic voting machines. :) Those are entity-like features. So which is it, value object or entity?

The reason this is confusing is that it's the wrong question. Put this way it's unanswerable: Florida might be /either/ a value object or entity in different models. The question you want to ask is, should Florida be an entity or a value object in OUR model? Sure, Florida has an ongoing identity in the "real world", but a model is never the real world. It leaves out almost all the details. That's what makes models useful. What really matters is whether different instances of Florida (for example, captured at different points in time) would need to be treated differently by THIS system (the one you're building). And the answer for most systems would certainly be no.

Think back to the water bottles for a moment. What is it that changed when Eric took a drink out of the bottle? The bottles were physically different before that. Perhaps one was upside down. Perhaps one was scratched. But those were not differences anyone cared about. We don't have a model in which we would do anything differently based on the bottle being scratched, but we do have a model in which we want not to drink from the same bottle as another person. As you can see, the event that "promoted" the bottle from being a value object to an entity is model-dependent. (Imagine a culture in which our particular model of hygiene doesn't have any currency; in that case bottles drunk from by different people might go back to being interchangeable.)

So, if the entity vs. value object question is determined by the model you're working with, what determines the model? There's actually a simple answer to that. The model is determined by what you're trying to DO with it. Remembering this helps you to know what details to leave out. And that's critical, because models that are cluttered with unnecessary detail are a lot harder to work with.

Why does whether the bottle has been drunk from matter in our model? To answer that, ask what our model is helping us do. What's its purpose? I would say its purpose is to quench our thirst while not picking up germs from other people. But if our purpose were instead to clean up the room after the class, things would be modeled differently. By the way, did you notice that I used other terms from the "domain" just now, when stating the model's purpose? "Germs" for example. In the thirst-quenching model we don't care about the individual identity of germs, so the little buggers are value objects. But say we were working on some highly specialized biotech research project...

Coming back to your Florida question, if we were working together on a project the discussion I would want to have would be this: "Sure, Florida might be an entity under some circumstances, but would tracking different instances of Florida have any conceivable effect on what we're trying to make our system do"? If our system's purpose is to sell books to people who live in the US, the answer is likely a definite no. Different instances of a Florida object (residing at different memory addresses on a computer) would have no visible effect on how our system processes book orders. On the other hand, say we're building a system for the Federal Elections Commission to track state compliance with electoral regulations. Now different instances of Florida might very well change the system's behavior. Well, one can play with this endlessly but by now you get the idea.

To sum up, entity vs. value object is determined by the model, which is determined by what you're trying to do in your domain.

I began by saying that typically, we want lots of value objects and just a few entities. You might ask why. One answer is that value objects are an order of magnitude simpler to work with. Because we don't care which one we have, we can pass them around freely. And because we don't care about their state changes, we can make them immutable. If we hand off a value object to some other code, we never have to worry about what might happen to it. And if we need to modify one ourselves, we just make a new one. In other words the dependencies we need to worry about are drastically fewer in the case of value objects than entities, making them one of our key weapons in the art of tackling complexity.

And there's another reason, too. As Eric's book describes at length, a good domain model is like a language that enables one to make statements about the domain - statements that are rich enough to be meaningful to domain experts, but also formal enough to be written in code. Well, what are these statements made out of? If all you have are entities and system types (integer, string, etc.) then you don't have a very expressive language and it will be hard to make statements in it that satisfy both criteria. What you want are lots of intermediate "building blocks" at your disposal that you can compose into meaningful statements. These are the concepts that turn up a lot in your domain but aren't the complex entities themselves; rather they're the things that the complex entities depend on and are made of. Those building blocks are typically value objects. So value objects are also one of our key weapons in the art of modeling domains. Those are two really important factors, which means that having a rich vocabulary of value objects is a big, big deal.

Dan