DDD Tactical approach - Aggregates and Repositories

Asked

Viewed 60 times

1

I am studying on DDD and trying to apply its concepts. I’m having doubts about some concepts with regard to the tactical part of DDD.

Problematic

Come on! Assuming I have an aggregate Client and this has a wish list. Each item in the list corresponds to a Product.

That said, if I need to remove an item from the list, I use the entity Client. Something like:

$client->removeFromWishList(Product $product))

The method removeFromWishList(...) contains some rules that need to be in compliance for removal. If everything is ok, the product will be removed from the wish list contained in the object Client.

But this removal is only in memory. So I use a Application Service, who has access to the repository that will handle the removal. The question is: What the repository containing the removal method should take as argument?


Approach

  1. If you receive as argument the object Client: How will I know which product I have to remove since such product is no longer on the wish list? Ex.:

    $clientRepository->removeFromWishList(Client $client)
    
  2. If you receive as argument the object Product or the product id which shall be removed: That way, I understand that I would be removing any product without going through the method removeFromWishList(...) ignoring the rules that guarantee the above mentioned removal.

    Ex.:

    $clientRepository->removeFromWishList(Product $product)
    

    Or:

    $clientRepository->removeFromWishList($productId)
    

It was not clear to me which of the approaches cited (or none of them...) would be ideal.

Likewise I do not understand if I will have to load all products from the wish list to the object Client whenever I want to remove a product from the list (going through the rules that ensure removal).

Thanks in advance for your attention.

1 answer

1

What should the repository containing the removal method receive as an argument? Basically the product id to be removed, the user’s session/cache id to confirm that it is removing from the "cart itself".

  • First of all, thank you for your attention. I understood your placement, though, in which case I could be removing an item from the cart without going through the removal rules, right? Even though before calling the repository method I perform the removal "in memory, that is, going through the method that ensures safe removal", I would have to pass the ids manually and without any guarantee of validation. (I don’t know if I was clear.... rs). At this point, any programmer could remove an item from a list and forget that they should have previously removed such an item by going through the domain removal method.

  • There would be no way to remove manually, this list is just the storage of what I INTEND to remove, the removal even is only effected by your "removeWish..." method with its rules. Even if it changes the values manually, they will be forced to go through your rules, as you showed "$client->removeFromWishList(Product $product))", here you are forcing the items (within $product) to go through "removeWish...", rules processing is on the server, not on the client.

  • I had posted this same question, however, in more detail in https://github.com/laravelbrasil/forum/issues/206

Browser other questions tagged

You are not signed in. Login or sign up in order to post.