Based on the same example for this question.

Within the Pro ASP.Net MVC 4 by Adam Freeman, there is a discussion on aggregates and aggregate roots with a simple auction system. There are members who bid, items that are bidded upon, and bids. The author says that there would be an aggregate of Item and Bid with Item being the aggregate root. The author then mentions that aggregates roots can be used to do a cascading delete, which for this example means that if an item is deleted, all bids on the items are deleted. This makes sense. The problem is, bids only belong to the item/bid aggregate, and not to a member/bid aggregate. If I delete a member of the system who places bids, it would seem reasonable that all their bids are deleted as well. Yet, I can't do that without 'break' the aggregate. I also can't simply get a members list of bids.

My level of confusion, given how simple the example is, makes me a bit worried.

Is this just a bad example, could member/bid be a valid aggregate instead and there is some level of arbitrariness in making the choice of your aggregates that is acceptable as long as you make a choice, is there some way to have models belong to multiple aggregates, or am I just missing something?

P.S. The answer in the question I linked says that domain driven development is just very tricky, but it doesn't go into enough details as to how it is tricky and why the trickiness induces confusion and as such my questions about it still remains.

1 Answer 1


Two bounded contexts can refer to the same object. But only one controls the lifespan of the object.

The bid belongs directly to the Auction BC. A book that I recommend to many people is Java Modeling in Color with UML it provides a great set of tools to help with domain modeling.

Color-based modeling categorizes domain objects into four archetypes: Person/Place/Thing, Role, Descriptor, and Moment/Interval.

I've gone back and forth about mapping the concepts in the book with DDD concepts. Specifically thinking about a heuristic for determining BCs and Aggregate Roots based on Archetypes.

What I do know is that Membership and Auctions are two separate BCs (in your example). The process of Managing membership has nothing to do with managing auctions (aside from the fact that members create/bid on auctions. Other than that, they're two separate systems

An Auction is an example of a Moment-Interval archetype, it happens over a given period of time (hence it's an Interval). Off of the Auction are several roles: the Auctioneer, the ItemForAuction, and possibly the WinningBidder. These roles are assigned to Person/Place/Thing archetypes.

For example there is a single Party in the system that represents me Mike Brown. Within the system, the Mike Brown entity might have several roles associated with it. One role would be Member (from the Membership BC) another might be Auctioneer (if I decided to put an item for auction) another might be Bidder (if I bid on an auction). The important thing is that no matter which role I play in the system, the data and functionality associated with that role is isolated to it. Think of roles as decorators, or hats that people wear depending on what they're doing.

If I have a hold of the Mike Brown entity. I can ask the entity "What roles do you have" or "Do you have the X role" and the entity should be able to answer. So I can say, Mike Brown give me your Auctioneer role. From the auctioneer role I should have operations like CreateAuction, CancelAuction, ListActiveAuctions, ListCompletedAuctions. In other words the Role is the engine of the system.

Remember I said that the Auction is an example of the Moment-Interval archetype. These represent significant events or periods within your domain. Another concept associated with a Moment-Interval is what's called Successors. For example a Bid is a Successor to an Auction. A bid only exist within the realm of a specific auction (i.e. a Bid is part of the Auction's Aggregate).

If the User or Member who created a bid is removed from the system, that does not negate the fact that a Bid was placed. (No more than Divorcing your wife negates that you had children together, the wife is no longer part of your Family aggregate, but the children very much are...let's ignore the fact that now the children belong to two Family aggregates).

What I am leaning toward as a hypothesis is that For every Moment-Interval, there is a primary Actor that would be the Role archetype. For instance, an Auctioneer is the primary Actor for the Auction M-I. He creates it. The other actors participate in it. I'm leaning toward saying the primary actor for an M-I would be the Aggregate root, except that a single Role entity can participate in multiple M-I.

So the Primary-Actor is a FACTORY for an M-I and controls the lifetime but the M-I itself would be the candidate for an Aggregate root. In this case Auction is an Aggregate root. And it's successors, roles, descriptors, and PPT, are part of its aggregate.

Membership as part of a separate bounded context shouldn't really have direct access to bids, or auctions. Deleting a member for me is actually terminating the Membership M-I (setting an end date on the membership). And any other logic involved in ensuring that the user does not have access. The member still exists, but is inactive. His historical bids are still there. Everyone is happy.

  • To make sure I'm understanding your point, you are saying that a member deletion should not cascade delete because they should still exist tied to an item (or to the one who put the item up for bid in your slightly more complex model). This reverses my question then, why should deleting the item cascade deletes to the bids since, even after the item is sold, the bids still exist as part of the history of what a member did? As you said, the historical bids need to still be there. Apr 22, 2014 at 14:13
  • Why would you delete the Auction? Was it cancelled or voided? If that's the case, I wouldn't delete but rather mark it as such. Unless it was deleted without any bids and say within a certain time period. Look at Stackoverflow. "Deleted" questions/answers don't go away. They're just hidden from most by status. Apr 22, 2014 at 15:33
  • I'm only considering deleting because that is what the example in the book is speaking of doing. Apr 22, 2014 at 16:29
  • There was a good discussion on the DDD/CQRS mailing lists about why hard deletes are an anti-pattern. I agree. Think of an order that is cancelled after it's shipped? If you delete the order, how do you track receipt of the return? You can't unring a bell deleting entities should be the exception, not the norm. Apr 22, 2014 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.