title: Few confusing things about expressing relationships with References and Repositories
body: <p>• We can express an <em>association</em> between two entities via <strong>object reference</strong> ( though a relationship between <em>Aggregate root</em> and its <em>internal entity</em> could also be expressed via a <em>method defined on a root</em> --> <code>SomeRootEnt.BorrowMeIntEnt(...)</code>  ) or via <strong>Repository</strong>, which would retrieve <em>related entities</em> from a database. <br />
  • When relationship is expressed via <em>Repository</em>, <em>client</em> would directly call a <em>Repository</em> to obtain <em>related entity(ies)</em> <br />
  • The decision on how to express a <em>relationship</em> is based on whether this <em>relationship</em> is required for <em>maintaining an integrity</em> ( and perhaps on whether <em>behavior</em> requires <em>association</em> to be able to express itself )</p>
  
  <p>1) If <em>relationship</em> ( say <strong>1:*</strong> ) is expressed via <em>Repository</em>, are <em>child entities</em> required to contain an <em>ID</em> of a <em>parent entity</em> ( Note: this question is assuming that either at least a parent is a root or that they all reside within same aggregate )? </p>
  
  <p>2) The <em>relationship</em> between <em>entities in different aggregates</em> should only be expressed by <em>IDs</em></p>
  
  <p>a) Why?</p>
  
  <p>b) Wouldn't such a <em>relationship</em> essentially be expressed via <em>Repository</em>?</p>
  
  <p>c) If yes to <strong>b)</strong>, this would also suggest that <em>associations</em> between <em>entities in different aggregates</em> in most cases aren't required for the purpose of supporting a particular <em>behavior</em>? If yes, why?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>2a) </p>
  
  <blockquote>
    <p>Expressing relationship with an identity reference is different from
    expressing the relationship with an object reference. The reason that
    the relationship should be expressed with an identity is to maintain
    transactional integrity - ie only a single aggregate will be modified
    in any given transaction. If an object reference was used, two
    aggregates could be affected by a transaction.</p>
  </blockquote>
  
  <p>I - I understand the point you're trying to make, since if relationship would be expressed with an <em>object reference</em>, then simply for the fact that aggregate A1 ( which is being modified ) is "physically" connected to another aggregate A2, it means one of A1's parts ( ie A2 &lt;--  in reality A2 is not really a part of A1, but hopefully you understand the point ) is not in sync with other parts?! </p>
  
  <p>II - But conceptually speaking, if we modify A1, then even if the relationship between the two is not expressed using <em>object reference</em>, the two aggregates are still out of sync, so in practical terms, what difference does it make whether A1 and A2 are physically connected?</p>
  
  <p>III - Anyways, why couldn't we in BOTH cases simply use <em>eventual consistency</em>?</p>
  
  <p><strong>SECOND UPDATE:</strong></p>
  
  <p>original_2) </p>
  
  <blockquote>
    <p>To be clear, relationships between root entities (ARs) should be
    expressed with identities. References between non-root entities in
    distinct aggregates should be forbidden.</p>
  </blockquote>
  
  <p>Can we have unidirectional associations traversable only from <em>A1 non-root entity(ies)</em>  to <em>A2 root entity</em> ( ie <em>non-root entity</em> in A1 would contain ID of A2 root )?</p>
  
  <p>2)
  a) </p>
  
  <p>I.</p>
  
  <blockquote>
    <p>If an object reference was used, two aggregates could be affected by a
    transaction.</p>
    
    <p>It creates a possibility of A2 being modified in the transaction which
    is modifying A1. Referencing A2 by identity eliminates this
    possibility. Also, things such as database locking won't apply to A2
    when loading A1.</p>
  </blockquote>
  
  <p>Ignoring for a moment the fact that DB locking won't apply to A2 when updating A1 - why shouldn't we in certain situations allow both A1 and A2 to be modified within a single transaction? </p>
  
  <p>I know aggregates define consistency boundary, but if in rare cases we need both A1 and A2 to be synchronized within same transaction, then only other alternative may be to convert both A1 and A2 into a single aggregate, which in that particular model may not be appropriate?! </p>
  
  <p>Thank you</p>