CODEWITHSUNDEEP
.netoopdesign-patternsdomain-driven-design
LuckyStrike
LuckyStrike

Reputation: 1493

Domain Driven Design lookup tables as aggregate root

We have a web application where you can access two services/functions ("Buy" and "Rent"). In a first step you have to chosse a ProductCategory from a DropDownList. Not every product category can be bought or rent. We have 5 product categories:

How can I design that in a Domain Driven way? In my oppinion the buy/rent property is not a property of the ProductCategory but of the Service itself: 

public class Service
{
     public string Name; // Buy or Rent
     public List<ProductType> AllowedTypes; 
}

Edit Second Example:

Both services have a few shared status (e.g. created or finished) but also special status (e.g. "Buy-Status-1"). Is it a good idea to use for both services the same status class? Or better a specialized class per service BuyStatus/RentStatus.

Upvotes: 2

Views: 305

Answers (1)

Wiktor Zychla
Wiktor Zychla

Reputation: 48314

I think it depends on whether the "buy/rent" vs "only buy/only rent" relation is static or dynamic.

If the relation is static (once for all) it could be just simpler to have this information directly on the ProductCategory. The less classes the better.

On the other hand, if the relation is dynamic then making another object responsible for maintaining such knowledge could make it easier to manage the dynamic state (for example, a product could be for rent only for some time and then "buy/rent" for yet some time etc.).

This follows an oop rule which says that properties are just values and when properties become more complicated (e.g. they change in time and you have to follow all changes) then you move them to separate classes.

Upvotes: 4

Related Questions