CODEWITHSUNDEEP
domain-driven-design
Marco
Marco

Reputation: 2473

Where to place this invariant?

I'm working on a side project to learn and apply DDD within the "Daily Deal' domain. In my purchasing context, i have an invariant where a user can only purchase 'x' amount of deals per deal.

so it seems wasteful for my deal aggregate to load all purchases from all users just to check and see how many times (if any) the user has purchased this deal. I see two ways i could go about this.

  1. Put this logic within a domain service which would allow a pre-condition to already have been met when the Purchase method on the Deal aggregate is invoked.

  2. My repository implementation could always populate the purchases collection of the deal for the purchasing user. hmm...not sure about this one.

any guidance would be great!

Upvotes: 4

Views: 249

Answers (1)

Tyler Day
Tyler Day

Reputation: 1718

I would take the second approach, but with one important change. I would instead create a value object called PurchasedDeal, that consists of just a DealID and Quantity field. The User aggregate could instead load a collection of this more lightweight purchase history object. Performance should be good with this approach, since I'm guessing that the average user will only have a few dozen purchase records.

Also remember that with DDD, you can and probably should have different models per bounded context. So you might design your User aggregate like this in the context of deals/purchasing. However, your User aggregate in another context would look different and not have a purchase history if it's not needed.

Upvotes: 2

Related Questions