Databases
StackOverflow2013
Postsdbo
POAggregate Root references other aggregate roots
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POAggregate Root references other aggregate roots
    primarykey
    data
    text
    <p>I'm currently working a lot with DDD, and I'm facing a problem when loading/operating on aggregate roots from other aggregate roots.</p> <p>For each aggregate root in my model, I also have a repository. The repository is responsible for handling persistence operations for the root. </p> <p>Let's say that I have two aggregate roots, with some members (entities and value objects).</p> <p>AggregateRoot1 and AggregateRoot2.</p> <p>AggregateRoot1 has an entity member which references AggregateRoot2.</p> <ol> <li>When I load AggregateRoot1, should I load AggregateRoot2 as well?</li> <li>Should the repository for AggregateRoot2 be responsible for this?</li> <li>If so, is it okay for the entity in AggregateRoot1 to call the repository of AggregateRoot2 for loading?</li> </ol> <p>Also, when I create an association between the entity in AggregateRoot1 to AggregateRoot2, should that be done through the entity, or through the repository for AggregateRoot2?</p> <p>Hope my question makes sense.</p> <p><strong>[EDIT]</strong></p> <p><strong>CURRENT SOLUTION</strong></p> <p>With help from <a href="https://stackoverflow.com/users/35389/twith2sugars">Twith2Sugars</a> I've come up with the following solution:</p> <p>As described in the question, an aggregate root can have children that have references to other roots. When assigning root2 to one of the members of root1, the repository for root1 will be responsible for detecting this change, and delegating this to the repository for root2.</p> <pre><code>public void SomeMethod() { AggregateRoot1 root1 = AggregateRoot1Repository.GetById("someIdentification"); root1.EntityMember1.AggregateRoot2 = new AggregateRoot2(); AggregateRoot1Repository.Update(root1); } public class AggregateRoot1Repository { public static void Update(AggregateRoot1 root1) { //Implement some mechanism to detect changes to referenced roots AggregateRoot2Repository.HandleReference(root1.EntityMember1, root1.EntityMember1.AggregateRoot2) } } </code></pre> <p>This is just a simple example, no Law of Demeter or other best principles/practices included :-)</p> <p>Further comments appreciated.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USChris Harrison
    1. UStschmuck
    plurals
    1. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POAggregate Root references other aggregate roots
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POAggregate Root references other aggregate roots
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POAggregate Root references other aggregate roots
      1. This table or related slice is empty.
      1. VTUpMod
    1. COPersonally I can see this current approach getting messy and I think DavidMasters84’s solution is more of an elegant solution. Ie keeping references as id's and extracting this type of domain logic to a domain service.
      singulars
      1. POAggregate Root references other aggregate roots
      1. USChris Moutray
    2. COMessy is a good adjective for this approach. I'm allowed to say that because I originally tried implementing this problem in the same way, and a mess is what I found myself in :) you might want to read suggestions here also for a similar question: http://stackoverflow.com/questions/2118088/aggregate-roots-how-far-does-the-rabbit-hole-go/4936021#4936021
      singulars
      1. POAggregate Root references other aggregate roots
      1. USDavid Masters
    3. COI hear you, but isn't repositories there to manage aggregate roots, and with some good will, relations between roots. And domain Services to handle behaviour that dosen't natural fit in a single entity? Seems to me that making the Domain Service resposible for handling references between roots is the wrong place when reading the definition of a Domain Service... I could be wrong, so a more backed up argument would be appreciated, thanks.
      singulars
      1. POAggregate Root references other aggregate roots
      1. UStschmuck
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload