Loading ...
Sorry, an error occurred while loading the content.
 

Re:Value object question

Expand Messages
  • Daniel Gackle
    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
    Message 1 of 15 , Nov 19, 2007
      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
    • James
      Dan, that s the single most helpful explanation of value objects I ve read yet. Thanks for that!! James
      Message 2 of 15 , Nov 19, 2007
        Dan, that's the single most helpful explanation of value objects I've read yet. Thanks for that!!

        James


        --- In domaindrivendesign@yahoogroups.com, "Daniel Gackle" <danielgackle@...> wrote:
        >
        > 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
        >
      • rlcorbin
        I second that. Thanks Dan! Rick From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of James Sent: Monday, November
        Message 3 of 15 , Nov 19, 2007

          I second that. Thanks Dan!

           

          Rick

           

          From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of James
          Sent: Monday, November 19, 2007 7:38 PM
          To: domaindrivendesign@yahoogroups.com
          Subject: [domaindrivendesign] Re:Value object question

           

          Dan, that's the single most helpful explanation of value objects I've read yet. Thanks for that!!

          James

          --- In domaindrivendesign@yahoogroups.com, "Daniel Gackle" <danielgackle@...> wrote:

          >
          > 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
          >

        • hal arnold
          ... Apart from the Repository/aggregate problem, we handle persistence with Hibernate for VO s by creating a hibernate custom type. The simple example is an
          Message 4 of 15 , Nov 19, 2007
            --- Sean Chambers <dkode8880@...> wrote:

            > I see I have touched on a particular topic that
            > really depends on the
            > context and there is no definate answer to this
            > particular example.
            >
            > In my context I would consider a State a value
            > object because it's
            > use will be very generic and it doesn't really take
            > on an identity of
            > it's own. I.e. my state is the same as yours.
            >
            > That being said, How would I now handle persistence
            > of the state
            > value object. Do value objects get their own
            > repository or are they
            > accessed from an aggregate root. I could see my
            > state objects being
            > used in more than one aggregate root, but perhaps
            > not. How are value
            > object management normally handled?
            >
            > Thanks for the info! It helps alot.
            >
            > Sean
            >

            Apart from the Repository/aggregate problem, we handle
            persistence with Hibernate for VO's by creating a
            hibernate custom type. The simple example is an
            association of an object that has some sort of state,
            where you wanted to represent the state as a value
            object, instead of a string. You can 'map' the object
            in Java world as the VO [maybe an enumeration], but
            have the representation in the db table as the string.
            So when you get ready to retrieve your object and it's
            associated state VO, hibernate auto-hydrates the
            correct association.
            And then: if you 'update' the association [as you
            might if you were doing a state transition], hibernate
            would happily dehydrate the association, so that you
            see the correct string representation in the db. Works
            mighty fine, lasts a long time.

            /h


            ____________________________________________________________________________________
            Never miss a thing. Make Yahoo your home page.
            http://www.yahoo.com/r/hs
          • Ertugrul Uysal
            That was really good, thanks. Can you give an example model with more value objects than entities? Like a model with five entities, just the names and a
            Message 5 of 15 , Nov 19, 2007
              That was really good, thanks. Can you give an example model with  more value objects than entities? Like a model with five entities, just the names and a simple description possibly.

              ----- Original Message ----
              From: Daniel Gackle <danielgackle@...>
              To: domaindrivendesign@yahoogroups.com
              Sent: Monday, November 19, 2007 9:20:54 PM
              Subject: [domaindrivendesign] Re:Value object question

              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



              Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
            • richard.pawson
              A Customer (Entity) might have the following (Value) objects associated with it: - Name - Address - TelephoneNumber - CreditCardDetails - Sex Note, as the
              Message 6 of 15 , Nov 20, 2007
                A Customer (Entity) might have the following (Value) objects
                associated with it:

                - Name
                - Address
                - TelephoneNumber
                - CreditCardDetails
                - Sex

                Note, as the previous poster said, these can't be universally be
                stated to be values, it depends on the exact business scenario, but
                there are many scenarios where these could be value objects. (For
                example, CreditCardDetails might be an entity if you allowed the
                person to have multiple cards and you needed to be able to mark a
                card as 'no longer valid', ensuring that this would be picked up in
                any unfulfilled order where that card was used).

                You might ask, why are these things value objects, and not simple
                attributes (e.g. Strings) of Customer. Well in each case they may
                hold useful methods and/or hide the particular implementation.

                For example, I have often used a (Value) Name object to hold multiple
                String attributes (FirstName, LastName etc). But the Name object
                hides the specific implementation behind methods such as String
                formalName(), String informalName(). This allows me to have multiple
                implementations of Name, thus coping with the fact that different
                ethnic names are structured very differently (e.g. Chinese Names).

                Why make Sex a value object? (BTW, nouns have 'gender', people
                have 'sex' !). Again, it is to hide the implementation. Many
                systems have just two values (Male, Female), but the ISO standard is
                four (including Unknown, and Not Specified), and you might upgrade
                from one to the other. The Sex object hides this behind methods such
                as boolean isKnownToBeMale() and boolean isKnownToBeFemale() - both
                of which may (correctly) return false if the sex is unknown or not
                specified.

                I have done a similar thing for a Birth object encapsulating the Date
                of Birth and information about whether/how this has been validated,
                and (in one situation) completely hiding the DoB behind methods such
                as isAgedOver(int targetAge).

                (My main context is government systems, where this stuff is
                important. I accept that it might be less important in other
                business contexts).

                Richard



                --- In domaindrivendesign@yahoogroups.com, Ertugrul Uysal
                <ertugrul_uysal@...> wrote:
                >
                > That was really good, thanks. Can you give an example model with
                more value objects than entities? Like a model with five entities,
                just the names and a simple description possibly.
                >
                > ----- Original Message ----
                > From: Daniel Gackle <danielgackle@...>
                > To: domaindrivendesign@yahoogroups.com
                > Sent: Monday, November 19, 2007 9:20:54 PM
                > Subject: [domaindrivendesign] Re:Value object question
                >
                >
                >
                >
                >
                >
                >
                >
                > <!--
                >
                > #ygrp-mkp{
                > border:1px solid #d8d8d8;font-family:Arial;margin:14px
                0px;padding:0px 14px;}
                > #ygrp-mkp hr{
                > border:1px solid #d8d8d8;}
                > #ygrp-mkp #hd{
                > color:#628c2a;font-size:85%;font-weight:bold;line-
                height:122%;margin:10px 0px;}
                > #ygrp-mkp #ads{
                > margin-bottom:10px;}
                > #ygrp-mkp .ad{
                > padding:0 0;}
                > #ygrp-mkp .ad a{
                > color:#0000ff;text-decoration:none;}
                > -->
                >
                >
                >
                >
                > 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
                >
                >
                >
                >
                >
                >
                >
                >
                >
                ______________________________________________________________________
                ______________
                > Be a better sports nut! Let your teams follow you
                > with Yahoo Mobile. Try it now.
                http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
                >
              • Sean Chambers
                +1 to that. that was extremely informative. There is so much useful information on this group. Thanks again! Sean ... I ve read ... The ... of object ...
                Message 7 of 15 , Nov 20, 2007
                  +1 to that.

                  that was extremely informative. There is so much useful information
                  on this group.

                  Thanks again!

                  Sean

                  --- In domaindrivendesign@yahoogroups.com, "rlcorbin" <rlcorbin@...>
                  wrote:
                  >
                  > I second that. Thanks Dan!
                  >
                  >
                  >
                  > Rick
                  >
                  >
                  >
                  > From: domaindrivendesign@yahoogroups.com
                  > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of James
                  > Sent: Monday, November 19, 2007 7:38 PM
                  > To: domaindrivendesign@yahoogroups.com
                  > Subject: [domaindrivendesign] Re:Value object question
                  >
                  >
                  >
                  > Dan, that's the single most helpful explanation of value objects
                  I've read
                  > yet. Thanks for that!!
                  >
                  > James
                  >
                  > --- In domaindrivendesign@yahoogroups.com
                  > <mailto:domaindrivendesign%40yahoogroups.com> , "Daniel Gackle"
                  > <danielgackle@> wrote:
                  > >
                  > > 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
                  > >
                  >
                • Ertugrul Uysal
                  Address is a common example of Value Objects, I believe, but Name and Sex are interesting ones. Our typical model with 100 entities would have at most 5 or 10
                  Message 8 of 15 , Nov 22, 2007
                    Address is a common example of Value Objects, I believe, but Name and Sex are interesting ones. Our typical model with 100 entities would have at most 5 or 10 types of value objects, mostly for financial amounts, some date information, addresses and sometimes as objects holding template information.


                    Considering the previous (nice) post, I thought others used much more. It still depends on the domain and requirements, in my eye.
                    For example, we had some similar requirements for Birth and Age for an application in health domain, but we did not make it a separate value
                    object, instead put Birth and Age logic in a Person object. Since it
                    was not used in any other objects other than Person or its descendants, things were fine.

                    Your examples are also very informative, interesting and detailed, thanks.

                    ----- Original Message ----
                    From: richard.pawson <rpawson@...>
                    To: domaindrivendesign@yahoogroups.com
                    Sent: Tuesday, November 20, 2007 12:39:36 PM
                    Subject: [domaindrivendesign] Re:Value object question


                    A Customer (Entity) might have the following (Value) objects
                    associated with it:

                    - Name
                    - Address
                    - TelephoneNumber
                    - CreditCardDetails
                    - Sex

                    Note, as the previous poster said, these can't be universally be
                    stated to be values, it depends on the exact business scenario, but
                    there are many scenarios where these could be value objects. (For
                    example, CreditCardDetails might be an entity if you allowed the
                    person to have multiple cards and you needed to be able to mark a
                    card as 'no longer valid', ensuring that this would be picked up in
                    any unfulfilled order where that card was used).

                    You might ask, why are these things value objects, and not simple
                    attributes (e.g. Strings) of Customer. Well in each case they may
                    hold useful methods and/or hide the particular implementation.

                    For example, I have often used a (Value) Name object to hold multiple
                    String attributes (FirstName, LastName etc). But the Name object
                    hides the specific implementation behind methods such as String
                    formalName(), String informalName(). This allows me to have multiple
                    implementations of Name, thus coping with the fact that different
                    ethnic names are structured very differently (e.g. Chinese Names).

                    Why make Sex a value object? (BTW, nouns have 'gender', people
                    have 'sex' !). Again, it is to hide the implementation. Many
                    systems have just two values (Male, Female), but the ISO standard is
                    four (including Unknown, and Not Specified), and you might upgrade
                    from one to the other. The Sex object hides this behind methods such
                    as boolean isKnownToBeMale() and boolean isKnownToBeFemale() - both
                    of which may (correctly) return false if the sex is unknown or not
                    specified.

                    I have done a similar thing for a Birth object encapsulating the Date
                    of Birth and information about whether/how this has been validated,
                    and (in one situation) completely hiding the DoB behind methods such
                    as isAgedOver(int targetAge).

                    (My main context is government systems, where this stuff is
                    important. I accept that it might be less important in other
                    business contexts).

                    Richard



                    --- In domaindrivendesign@yahoogroups.com, Ertugrul Uysal
                    <ertugrul_uysal@...> wrote:
                    >
                    > That was really good, thanks. Can you give an example model with
                    more value objects than entities? Like a model with five entities,
                    just the names and a simple description possibly.
                    >
                    > ----- Original Message ----
                    > From: Daniel Gackle <danielgackle@...>
                    > To: domaindrivendesign@yahoogroups.com
                    > Sent: Monday, November 19, 2007 9:20:54 PM
                    > Subject: [domaindrivendesign] Re:Value object question
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    > <!--
                    >
                    > #ygrp-mkp{
                    > border:1px solid #d8d8d8;font-family:Arial;margin:14px
                    0px;padding:0px 14px;}
                    > #ygrp-mkp hr{
                    > border:1px solid #d8d8d8;}
                    > #ygrp-mkp #hd{
                    > color:#628c2a;font-size:85%;font-weight:bold;line-
                    height:122%;margin:10px 0px;}
                    > #ygrp-mkp #ads{
                    > margin-bottom:10px;}
                    > #ygrp-mkp .ad{
                    > padding:0 0;}
                    > #ygrp-mkp .ad a{
                    > color:#0000ff;text-decoration:none;}
                    > -->
                    >
                    >
                    >
                    >
                    > 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
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    ______________________________________________________________________
                    ______________
                    > Be a better sports nut! Let your teams follow you
                    > with Yahoo Mobile. Try it now.
                    http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
                    >





                    Yahoo! Groups Links












                    ____________________________________________________________________________________
                    Get easy, one-click access to your favorites.
                    Make Yahoo! your homepage.
                    http://www.yahoo.com/r/hs
                  • rickardoberg
                    (My first post, just found this group, hey there everybody! :-) ... This is an interesting observation, and a similar one could be made for services vs
                    Message 9 of 15 , Nov 23, 2007
                      (My first post, just found this group, hey there everybody! :-)

                      --- In domaindrivendesign@yahoogroups.com, Ertugrul Uysal
                      <ertugrul_uysal@...> wrote:
                      > 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 :))

                      This is an interesting observation, and a similar one could be made
                      for services vs entities. If an "Entity" implements a "Service"
                      interface then when a client request something that can handle the
                      Service interface you may not care which particular instance is
                      returned. Just that it is something that has a particular interface.

                      If you then learn that one possible instance is next door and another
                      is on another continent you may instead want to say "I want *that*
                      instance please". So if something is an Entity or a Service can also
                      depend on the actual context. This can then be abstracted by putting
                      the requestor and service instance in a context where it is obvious
                      that when the requestor asks for the service it will get a reference
                      to the one next door instead of the one on another continent, but
                      without having to explicitly say that this is important.

                      So, context matters :-) Hence, model it explicitly.

                      /Rickard
                    Your message has been successfully submitted and would be delivered to recipients shortly.