Domain model aggregates

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?

score 3 · Accepted Answer · answered Nov 16 '12 at 15:13

3

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.

answered Nov 16 '12 at 15:13

MikeSW

16,140
3
39
53

So how would you retrieve a member's bids? I suppose that the Member class would need to reference the Items on which this member bid. Then on the Item aggregate root there could be a function to retrieve a member's bids for this item. – Meta-Knight Nov 16 '12 at 15:48
I wrote that Item and Member are AR. Hmm, I'm not agree that aggregates may very in different BC in one Domain model. – Danil Nov 16 '12 at 15:56
@Meta-Knight Modelling the domain has nothing to do with database storage and this example is very simplistic so it resembles how the ORM entities might be modelled but that's it. I'm always considering the domain and the persistence different so I don't care about storage when I'm dealing with the domain. – MikeSW Nov 16 '12 at 16:23
@Danil Member is NOT an AR in this context. Why would the BC matter if all the aggregate are the same? Btw, they might or might not be, depneding on the domain. – MikeSW Nov 16 '12 at 16:26

score 1 · Answer 2 · edited May 23 '17 at 11:56

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.

Domain model aggregates

2 Answers2