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

Re: [domaindrivendesign] Re: Customer Entity interaction with Order Entity

Expand Messages
  • Paul Stovell
    +1 with Eben. Just because Customer *references *Order doesn t necessarily mean Order falls within the Customer aggregate root. The customer s addresses might,
    Message 1 of 9 , Jan 14, 2009
    View Source
    • 0 Attachment
      +1 with Eben.

      Just because Customer references Order doesn't necessarily mean Order falls within the Customer aggregate root. The customer's addresses might, but the orders can be independent (for example, you might have a service that processes all new orders no matter who the customer is. Having to go Customer->Orders makes no sense in this scenario).

      From a domain point of view, you can even question the validity of those references (Customer has reference to a list of Orders). How often will you actually need *all* orders for a customer? In some systems it makes sense, but in others, one customer might make many orders. Chances are you want orders for a customer between a date range, or orders for a customer that aren't processed yet, or orders which have not been paid, and so on. The scenario in which you'll need all of them might be relatively uncommon. However, it's much more likely that when dealing with an Order, you will want the customer information. So in code, Order.Customer.Name is useful, but Customer.Orders[0].LineItem.SKU - probably not so useful. Of course, that totally depends on your business domain.

      Page 127 in Evan's DDD provides a good demonstration of this. In the example, it's clear that a Car is related to a Customer, but the car's aggregate root only includes the wheels, tyres, and so on. You can work with both Cars and Customers independently.

      Paul




      On Thu, Jan 15, 2009 at 3:18 PM, Eben Roux <eben@...> wrote:

      Hello Dan,

      I ask myself a simple question to determine whether something needs to
      be an aggregate: "Does it make sense to work this item in isolation?"

      What does the question mean?

      For Order->OrderLine:

      - do I ever want to add a new Order directly to the DB? Yes.
      - do I ever want to add a new OrderLine directly to the DB? No.

      For all the Yes answers I will need an Aggregate and all the No
      answers will belongs to something else.

      I hope this helps and if I am on the wrong track please help me!

      Regards,
      Eben


    • Peter Morris
      ... Just because Customer *references *Order doesn t necessarily mean Order falls within the Customer aggregate root. The customer s addresses might, but the
      Message 2 of 9 , Jan 18, 2009
      View Source
      • 0 Attachment
        >>
        Just because Customer *references *Order doesn't necessarily mean Order
        falls within the Customer aggregate root. The customer's addresses might,
        but the orders can be independent (for example, you might have a service
        that processes all new orders no matter who the customer is. Having to go
        Customer->Orders makes no sense in this scenario).
        <<

        The very fact that you would want to pull up an order without having to go
        to the customer first means it is not part of the "aggregate", whereas the
        user wouldn't want to pull up an order line individually they'd want to pull
        up the whole order and look at a specific line.



        Pete
        ====
        http://mrpmorris.blogspot.com
        http://www.capableobjects.com - Think domain, not database
      • xlat3ralusx
        Thanks to everyone that answered my question. Your responses have shed some light on the subject. I recently purchased DDD from Evens, as well as Nilsson s
        Message 3 of 9 , Jan 18, 2009
        View Source
        • 0 Attachment
          Thanks to everyone that answered my question. Your responses have
          shed some light on the subject. I recently purchased DDD from Evens,
          as well as Nilsson's Applying DDD and Patterns w/C#. I usually find
          technical books bland, but I am actually enjoying the reading.

          Thanks again,
          Dan


          --- In domaindrivendesign@yahoogroups.com, Paul Stovell <paul@...>
          wrote:
          >
          > +1 with Eben.
          >
          > Just because Customer *references *Order doesn't necessarily mean
          Order
          > falls within the Customer aggregate root. The customer's addresses
          might,
          > but the orders can be independent (for example, you might have a
          service
          > that processes all new orders no matter who the customer is. Having
          to go
          > Customer->Orders makes no sense in this scenario).
          >
          > From a domain point of view, you can even question the validity of
          those
          > references (Customer has reference to a list of Orders). How often
          will you
          > actually need *all* orders for a customer? In some systems it makes
          sense,
          > but in others, one customer might make many orders. Chances are you
          want
          > orders for a customer *between a date range*, or orders for a
          customer that
          > *aren't processed yet*, or orders which *have not been paid*, and
          so on. The
          > scenario in which you'll need all of them might be relatively
          uncommon.
          > However, it's much more likely that when dealing with an Order, you
          will
          > want the customer information. So in code, *Order.Customer.Name* is
          useful,
          > but *Customer.Orders[0].LineItem.SKU* - probably not so useful. Of
          course,
          > that totally depends on your business domain.
          >
          > Page 127 in Evan's DDD provides a good demonstration of this. In the
          > example, it's clear that a Car is *related* to a Customer, but the
          car's
          > aggregate root only includes the wheels, tyres, and so on. You can
          work with
          > both Cars and Customers independently.
          >
          > Paul
          >
          >
          >
          >
          > On Thu, Jan 15, 2009 at 3:18 PM, Eben Roux <eben@...> wrote:
          >
          > > Hello Dan,
          > >
          > > I ask myself a simple question to determine whether something
          needs to
          > > be an aggregate: "Does it make sense to work this item in
          isolation?"
          > >
          > > What does the question mean?
          > >
          > > For Order->OrderLine:
          > >
          > > - do I ever want to add a new Order directly to the DB? Yes.
          > > - do I ever want to add a new OrderLine directly to the DB? No.
          > >
          > > For all the Yes answers I will need an Aggregate and all the No
          > > answers will belongs to something else.
          > >
          > > I hope this helps and if I am on the wrong track please help me!
          > >
          > > Regards,
          > > Eben
          > >
          > >
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.