When to use association in stead of id reference?

[islomic]

Hi,
I just wonder if there exists any rules/guidelines on when to use
association (OrderItem.Order) and when to use id reference
(OrderItem.OrderID)?

I guess the associations are only allowed between objects wirhin same
aggregate, because you dont want the tight coupling between
aggregates? When crossing aggregates, id references should be used?

Im I right?

Ismar

[islomic]

Addition to my post: and what about when you have relationship between
aggregate roots Member (AR) and Order (AR, which contains a list of
OrderItems)?

[Yves Reynhout]

An "association" is something left over from ERD. Erase the term from
your mind. Model it explicitly, it's a missing concept in your domain,
waiting to emerge. Most of the time it's a transaction/event (a
registration of something that happened at a place, between people and/
or a thing). When establishing/dissolving these "collaborations",
listen carefully to your domain experts. They will point you in the
right direction when it comes to decide what to keep track of, inside
your aggregate that is.

public class Order {
public void AddOrderLineItem(ProductDescription productDescription,
ProductUnitPrice pricePerUnit, Amount amount) {
// Here you decide what state you're gonna keep track of - usually
it's to make decisions later on based on this state; sometimes it's to
"feed" context to an event

[islomic]

Hi,
Thanks for your post. Not sure if I got answer on my question. With
association im thinking on realizing/implementing the relationship by
reffering to datatypes/objects (Order.Member) instead of id references
(Order.MemberId).

Ismar

[Nuno Lopes]

Hi,

> I guess the associations are only allowed between objects wirhin same
> aggregate, because you dont want the tight coupling between
> aggregates? When crossing aggregates, id references should be used?
>
> Im I right?

In DDD the conceptual integrity of an association between two Classes of Objects are only maintained within an Aggregate. Between Aggregates is not maintained.

For instance. If Purchase Order and PO Lines are part of the same Aggregate, the conceptual integrity of an association between them maintained.

Now say an Purchase Order and a Shipping Order part of distinct Aggregates. The conceptual integrity of an association between both is not maintained by the means provided by the Aggregate pattern.

Say that for instance a Purchased Order cannot be cancelled once a Shipping Order is fulfilled.

Using DDD patterns this cannot be absolutely guaranteed without breaking the conceptual boundaries of an Aggregate. So what you do is a best effort to enforce such constraint in the PO, yet we need to think about cases where it was not possible.

You may ask why is not possible? I would discuss the answer to that question with the domain expert.

Cheers,

Nuno

[Ian Cooper]

Hi Ismar,

Short answer: yes

Longer answer: One way of looking at an aggregate is to understand it
is a way of issuing a coarse grained lock i.e. providing a
transactional and consistency boundary. When you lock to avoid
concurrency updates you want to avoid anyone else also trying to
update parts within the graph you intend to update. Now in a free for
all, with no aggregates it is hard to predict what parts of the graph
someone else might update and how they overlap with yours. That
creates a lot of possibility for conflict. An aggregates asks us to
predecide what portions we will lock, and ensure that they don't cross-
over. In that way we can reduce conflict to folks trying to update the
same aggregate.To control conflicts we have the whole group share one
version. This allows us to check for conflict by updating the version
when we want to update, first checking that we have the current
version. To use a single version we have to be very careful about
folks breaking this scheme by trying to update a part of the aggregate
without updating our group version. Now how you enforce this depends
on what you are using to provide your persistence, the original Fowler
Coarse Grained Lock pattern talks about shared locks or pointers to
the root. However with something like NHibernate all this is fairly
awkward and you can end up populating backpointers in interceptors or
making the root a facade that you push all access through so that the
version gets updated. Either way the problem with an association is
the temptation for a developer to navigate it without realizing that
they have crossed a boundary that requires them to do something to
update another aggregate's version etc. This is true even if the
pointer is to another aggregate root, because simply traversing that
relationship won't force any kind of update to the version. For that
reason folks realized that storing only Ids of other aggregate roots,
forced folks to be explicit so that they realized they were crossing a
boundary. That also leads us in to raising domain events in response
to changes in an aggregate that other aggregates may need to apply.

[Ian Cooper]

--Wit some whitespace ;-)

Short answer: yes

Longer answer
One way of looking at an aggregate is to understand it is a way of
issuing a coarse grained lock i.e. providing a transactional and
consistency boundary. When you lock to avoid concurrency updates you
want to avoid anyone else also trying to update parts within the graph
you intend to update. Now in a free for all, with no aggregates it is
hard to predict what parts of the graph
someone else might update and how they overlap with yours. That
creates a lot of possibility for conflict.

An aggregates asks us to predecide what portions we will lock, and

ensure that they don't cross-over. In that way we can reduce conflict

[islomic]

Ian, your post really helped me understanding when to use association
and when to use Id's. Thank you for your time!

Regards Ismar