Personally I think it should be called the 'Suggestion of Demeter'.
Law is too strong a word in this case.

I'm certainly not opposed to OrderCount style properties, I've made
them plenty of times; often simply because Orders returns an
IEnumerable<Order>.
However, it doesn't feel right to me to say that Customer.Orders.Count
is bad. Inappropriate sometimes, but not simply bad.

Paul Batum

On Wed, Aug 20, 2008 at 10:25 PM, John Teague <jcteague <at> gmail.com> wrote:
> Paul, I agree with your clarifications of aggregates.
>
> However, unrelated to the definition of an aggregate, Customer.Orders.Count
> is violating Law of Demeter. This may or may not be a problem for a given
> domain. Even though the name has Law in it, it can be broken, but one must
> know when it's okay to deviate from the principles.
>
> Violating Demeter creates tighter coupling in your domain. Now Customer
> must have an Orders object, it can't be null and it must have a Count
> property.
>
> John Teague
>
>
> On Wed, Aug 20, 2008 at 4:08 PM, Paul Batum <paul.batum <at> gmail.com> wrote:
>>
>> Jason's explanation of aggregates is contrary to my interpretation of
>> the description provided by Evans in DDD.
>> Assuming you decide that orders are indeed part of the customer
>> aggregate, its still fine to expose the order object to outer layers.
>> However you should not allow anything outside the aggregate to hold a
>> persistent reference to an order, nor should you allow an order to be
>> retrieved directly (they should be retrieved via the customer object).
>> I think Customer.Orders.Count is fine.
>>
>> Am I mistaken?
>>
>> Paul Batum
>>
>> On Mon, Aug 18, 2008 at 8:33 PM, jasonmeckley <jasonmeckley <at> gmail.com>
>> wrote:
>> > Entities are mutable objects that contain an identifier to
>> > differentiate instances (usually this relates to a PK in the database,
>> > but it doesn't have too). Customer, Order, User are all examples of
>> > common entities.
>> >
>> > Value Objects are immutable and are not unique. to "change" a VO you
>> > just replace it with a new one. The Money VO is the most common
>> > example of a value object.
>> >
>> > Aggregates (roots) is where clients access the domain. clients being
>> > any code which accesses the object outside the core doamin. one of the
>> > rules is that you should never expose objects related to the root. for
>> > example a customer has a collection of orders: you should not expose
>> > the orders, instead provide an aggregate member to get the number of
>> > orders.
>> > Bad: Customer.Orders.Count
>> > Good: Customer.NumberOfOrders
>> > This promotes encapsulation. you can also change the implementation of
>> > Orders within Customer and not effect the rest of your code base
>> >
>> > Jason
>> > --- In domaindrivendesign <at> yahoogroups.com, elton albuquerque
>> >
>> > <eltondealbuquerque <at> ...> wrote:
>> >>
>> >> What is the difference between the groups of
>> >> patterns:
>> >> 1 - Entities, Values Aggregate Objects ...
>> >> 2-Shared Kernel,
>> >> Distillation, ... conformist
>> >>
>> >>
>> >> Elton
>> >>
>> >>
>> >>
>> >> Novos endereços, o Yahoo! que você conhece. Crie um email novo
>> > com a sua cara <at> ymail.com ou <at> rocketmail.com.
>> >> http://br.new.mail.yahoo.com/addresses
>> >>
>> >
>> >
>
>

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___