1

I recently started learning about DDD and I'm in the process of designing my first solution. I have a business requirement to design solution for Auction module and there are many types of auctions like car auction, property auction etc. all auctions types share same set of properties with custom properties to each type like:

class Auction
{
  int AuctionId;
  decimal MinAmount;
  datetime StartDate;
  int Duration;
}

class LicensePlateAuction : Auction
{
  string LicensePlatePrefix; //like ABC, KLL ....
}

class CarAuction:Auction
{
  string EngineSize;
}

and the database tables are Auction for persistence of Auction entity and one table for each type to keep the custom properties.

well the requirements are not really like the above but just tried to give simple and close example.

the question is what are the aggregates in my example? is it CarAuctionAgg and LicensePlateAuctionAgg?

if yes then as I understood there should be one repository per aggregate, then in case of creating auctions of the two types should I insert to the Auction table from both repositories? or I should have a separate repository for the Auction entity?

1 Answer 1

1

The Auction hierarchy statically knows too much about the item. Every auction should be able to describe the item. That description could be dynamic. A string. It doesn't have to statically know what it's describing.

If, let's say, you needed to list items sorted by engine size this should not be a feature offered by Auction. This would be a feature that requires you to know we're talking about Cars. That's where this should be provided. And so not part of the Auction interface.

Now, let's say, you needed to list items sorted by size. And every auction item had a size. That could be Auction functionality. Because it doesn't require knowledge of exactly what type the item is.

And so you can aggregate all auction items together, if you're willing to lump their functions together. If not, you're going to want to separate them so you know what you're talking about.

4
  • I got your point and I think in my example above I did not give an appropriate example of the real issue. the actual design I have is ` <<AggRoot>> class Auction { AuctionId: Int StartAt: datetime Duration: Int MinStartAmount: decimal MinOutbidAmount: decimal AuctionType: byte AuctionItems: List<AuctionItems> } <<Entity>> class AuctionItem { AuctionItemId: Int Value: string Description: string AuctionId: Int } ` Jul 26 at 15:18
  • now we have Auction for License plates and when creating the Auction you provide the base of the plate number like "AAA, BCA, ..." and the items to auction at will be "AAA001, AAA002 etc..." but somehow I need to connect between the Auction and the base characters of the plate numbers like the Auction id x is for "xxx" plate base. so the auction type in my case is licensePlate auction and the items are the plates base characters + generated numbers. Jul 26 at 15:20
  • and in case we have in the future something like Cars auction for all cars engine size xxx then the items I assume should be all cars of all models with engine size xxx. so the question is should I have two aggregate for each type of auction? or one aggregate (AuctionAggregate) is enough? Jul 26 at 15:20
  • I can only answer the question you asked. Sounds like you need a new question. Jul 26 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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