Home/ Questions/Q 7692701
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T20:54:47+00:00

We have a web application where you can access two services/functions (Buy and Rent).

  • 0

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:

  • A: Buy/Rent
  • B: Buy/Rent
  • C: Buy/Rent
  • D: Only Buy
  • E: Only Rent

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0