title: Domain Driven Design when you can resign to only reference between aggregates by ID
body: <p><strong>To sum up</strong>, I am going to ask:</p>
  <p>a) It makes sense to prevent the use of direct object references between aggregates in all scenarios?</p>
  <p>b) how can there be collisions in an optimistic concurrency control in relationships between aggregates using direct object reference but with lazy load?</p>
  <p><strong>Long explanation</strong></p>
  <p>Taking a look at classical resources about DDD: blue book, red book and lots of posts here, the rule of thumb is always the same: &quot;different aggregates must be referenced between them by IDs not using 'direct objects reference'&quot;.</p>
  <p><strong>The arguments in favor are:</strong></p>
  <p>A) Aggregates with inferred object references are thus automatically smaller because references are never eagerly loaded ( red book)</p>
  <p>B) It prevents updating more than one aggregate in a single transaction (If you don’t hold any reference, you can’t modify another Aggregate, red book)</p>
  <p>C) It forces all connected ARs to be in the same database.</p>
  <p>D) If you do EntityA-&gt;getEntitiesB() maybe you have a million B's and you are going to cause memory problems</p>
  <p>E) If you go for a pessimistic concurrency control you are going to have a lot of blocks</p>
  <p>F) You are going to have a lot of collisions using optimistic concurrency control</p>
  <p>I know that in the DDD world you always have a big &quot;depending on&quot; and a lot of trade-offs, so IMHO, taking into account that I'm working in a PHP environment using Doctrine as ORM and the application will not grow to sharding.</p>
  <p><strong>So, in my scenario I will refuse above reasons:</strong></p>
  <p>A) =&gt; is not a problem here, I am using Lazy Loading.</p>
  <p>B) =&gt; if you pay attention and use doctrine DEFERRED_EXPLICIT you don't have problems.</p>
  <p>C) =&gt; not problems because no database sharding is expected.</p>
  <p>D) =&gt; It could be but, not planned, due to the size of the application or can be optimized specifically using a repository method and paying attention.</p>
  <p>E) =&gt; Not using pessimistic concurrency control</p>
  <p>F) =&gt; no idea¿? I have been doing some POCs and I don't get a version increment in EntityA, when I do entityA-&gt;addEntityB(entityB) or entityA-&gt;removeEntityB(entityB).</p>
  <p>And in this scenario, I guess I have more advantages using direct object references:</p>
  <p>ADV1) The relationship is reflected in the domain (rich and encapsulated) and I can test my domain relationships in a domain layer.</p>
  <p>ADV2) I don't need additional hops between domain, application layer, and repository to retrieve relationships (at least not the biggest ones).</p>
  <p><strong>So my questions are:</strong></p>
  <p>a) It makes sense to prevent the use of direct object references between aggregates in all scenarios/applications?</p>
  <p>b) how can there be collisions in an optimistic concurrency control in relationships between aggregates using direct object reference but with lazy loading?</p>
  <p><strong>References:</strong></p>
  <p>Red Book: <a href="https://www.informit.com/articles/article.aspx?p=2020371&amp;seqNum=4" rel="nofollow noreferrer">https://www.informit.com/articles/article.aspx?p=2020371&amp;seqNum=4</a></p>
  <p>StackOverflow: <a href="https://stackoverflow.com/questions/11631524/domain-driven-design-and-aggregate-references">Domain driven design and aggregate references</a></p>
  <p>DDD in PHP: <a href="https://www.amazon.es/Domain-Driven-Design-PHP-Carlos-Buenosvinos/dp/1787284948" rel="nofollow noreferrer">https://www.amazon.es/Domain-Driven-Design-PHP-Carlos-Buenosvinos/dp/1787284948</a></p>
  <p>Lazy loading and domain: <a href="https://enterprisecraftsmanship.com/posts/domain-model-purity-lazy-loading" rel="nofollow noreferrer">https://enterprisecraftsmanship.com/posts/domain-model-purity-lazy-loading</a></p>