Question

I've just read a chapter about aggregates and found that I misunderstand something. We have three objects: Member, Item, Bid. Here is code snippet from the book:

public class Member
{
   public string Id {get; set;}
   ...
}

public class Item
{
   public string Id {get; set;}
   public IList<Bid> Bids {get; set;}
   ...
}

public class Bid
{
   public Member Member {get; set;}
   ...
}

Autor wrote that Item and its bids is one aggregate as a Bid doesn't make sense without an Item. So Item and Member are aggregate roots. However I think that Bid doesn't make sense without the member too. And it seems that it is logical. So what is a Bid in this situation? Is it a part of Item aggregate?

Was it helpful?

Solution

First of all, aggregate and aggregate root are different concepts. In this case, Item and Bid might be part of the same aggregate but only one, I think the Item is the aggregate root (AR).

Defining which class is the AR is higly dependent on the bounded context (BC). Also, that Member class may be represented only as a simple Id in that BC, that's not the Member you might use in a different BC (you see DDD is VERY tricky).

The Item involves both Bid and Member, all together form an aggregate but the Item is the aggregate root i.e the facade object used by others to manage the aggregate.

OTHER TIPS

While not exactly the same, this is very similar to this SO question, where Richard Cirerol's answer is a decent one.

But, I would point you to the book on page 71, where the diagram shows that bid has a reference to a member and can therefore reach OUT to get that information, but the member cannot reach IN. The only way to reach in is via the item. So, the item is the control point in the example. This helps keep the lines of what can do what clear and transactional.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top