The behavior of aggregates in DDD should/can be like the behavior of subjects, or should/can be like actions on objects?

Question

Software design

I will give two examples. Let's omit some even important things from DDD now, the examples are intended to show the essence of the issue.
How it is more correct to make from the point of view of DDD?
There are two root aggregates, seller and ad. The seller can edit the ad in these examples:
1.
If the models must reflect the real business logic. It is the Seller who changes the ad. The client layer calls the changeAdvertName() and changeAdvertCost() methods of the Seller aggregate. This has the advantage of, say, access checking, we can see that the Seller can only change their Adverts. This is the first way to do it.

//Client layer call seller.changeAdvertName(name)

    //AR Seller
    class Seller{
        adverts
        changeAdvertName(advertId, name){
            adverts[advertId].changeName(name)
        }
        changeAdvertCost(advertId, cost){
            adverts[advertId].changeCost(cost)
        }
    }

    //AR Advert
    class Advert{
        name
        cost
        changeName(name){
            this.name = name
        }
        changeCost(cost){
            this.cost = cost
        }
    }

2.
Another option is where the client layer will call changeName and changeCost directly on the Advert aggregate. I often see such an implementation in various examples.

//Client layer call advert.changeName(name)

    //AR Advert
    class Advert{
        name
        cost
        changeName(name){
            this.name = name
        }
        changeCost(cost){
            this.cost = cost
        }
    }

Are both options valid in DDD? And which one is more correct and logical in terms of DDD?

Answer 1

https://stackoverflow.com/questions/45927675/behav...

Answer 2

IMHO.
if we consider the advantages of the first solution. it is very simple, trivial, has few components - and therefore contains potentially fewer bugs.
cons: it's tough. adverts is hard-coded into an array, has no logic of its own, and is of little use.
Let's take a slightly improved solution: there is a seller, an advert interface, and there is an adverts storage interface. and there is an implementation of advertsImpl, advertImpl. Those. smashed the seller, storage and advert. we can change them as we wish, subject to the contract - compliance with the interfaces.
Plus: independence. The storage logic will be in the storage and not in the seller. The flexibility is that we can write an implementation of it using an array in memory, various kinds of databases, or storing data on the network.
Minus more classes, more text, more errors.
Further.
We make a separate seller, a separate advert control layer, a separate advert.
plus: a very flexible solution, in the layer we can implement any logic for working with adverts (for example, related adverts, or related to other entities), etc.
minus: the most difficult and muddy solution.
Total: you need to choose an effective solution for the task that is worth it. that is, you need to predict how the system will develop.
those. there is no abstract correct solution. and especially the only correct one.
it is probably possible to make it as simple as possible, but leaving the possibility to develop the system.