We have the following system:

References that identify a product and have a family which identifies a group in which the reference belongs.

Families that are a way to group references, for example, if we sell electronics we could have a family to identify the keyboards, another to identify the screens and so on.

Rates that identify how the price of a reference changes depending on some variables, a rate has a list of family rates were, for the specific rate, each family can modify the price of the product via percentage or a fixed value and discounts. The rate has a list of reference rates, which every reference rate has a rate detail which contains the price of the reference and the discounts to apply depending on the quantity requested. When the fixed value or percentage value of a family rate is changed, every reference rate detail with the same family as the family rate changed is updated with the new calculated values and discounts. A reference rate detail can be manually set by the user and locked so any change in the family rate for the family of the reference doesn't change the values of the reference rate detail.

Clients that have a list of fixed prices for specific references, a specific rate for the client, and a list of rates for family so a client can have different rates depending on the family of the reference he is ordering.

So went a client makes and order and adds references to it, we calculate the price of the order doing the following: - First, we look if the client has a specific price for the reference, if it has it returns the price. - If the client does not have a specific price for the reference, we try to get the client rate for the family of the reference, if there is no rate on the rates_family for the specified family for this client we use the rate of the client. - When we have the rate, we get the reference rates detail for the specific reference and rate, and with the details we get the price of the reference.

Now that's how a price is calculated, but what happens when we add a new rate, or a new family, or a new reference?

When a new rate is added, the system creates a list of family_rates for each family that exists, it also creates a list of reference rates with its details for every reference that exists. When a new family is added, the system adds to every rate a new family_rate with the new family. When a new reference is added, the system adds to every rate a new reference_rate and detail with the new reference.

That's how the system works, the system is pretty old and we are updating it following the DDD approach and after looking into it that's how I think It should be:

- Reference (Aggregate Root)
    - familyId (Reference) 

- Family (Aggregate Root)

- Rates (Aggregate Root)
    - Family Rates (Entity)
        - familyId (Reference)
    - References Rates (Entity)
        - referenceId (Reference)
        - Reference Rate Details (Entity)

- Client (Aggregate Root)
    - Price References (Entity)
        - referenceId (Reference)
    - rateId (Reference)
    - Rates Families (Entity)
        - familyId (Reference)

There's basically 4 aggregate roots, family and rate can live without any of the other entities, reference needs a family, but all other properties and functionalities of a reference do not depend on the family so I think it's an aggregate root with a reference to the family, the client is exactly the same as the reference but with the rate, it needs a rate but it is a reference to the rate. I was wondering about if the family rates, reference rates and price references should be entities or value objects, I think they are entities because they aren't immutable, they can change its values.

I know when designing I should not take into account how it is stored, but I'm inevitably influenced by the old system and how It was structured in the database.

My question is if this approach seems correct? Should the price references, reference rates, and family rates be a value object instead of an entity? Maybe there aren't four aggregate roots.

Thanks for your attention



Your Answer

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

Browse other questions tagged or ask your own question.