Поведение агрегатов в DDD должно/может быть как поведение субъектов или должно/может быть как действия над объектами?

Question

[yurygolikov]

Приведу два примера. Опустим некоторые даже важные вещи из DDD сейчас, примеры призваны показать суть вопроса.

Как правильнее сделать с точки зрения DDD?

Есть два корневых агрегата, продавец и объявление. Продавец может редактировать объявление в данных примерах:

1.

Если модели должны отражать реальную бизнес логику. То именно Seller изменяет объявление. Те клиентский слой вызывает методы changeAdvertName() и changeAdvertCost() агрегата Seller. Это дает такое преимущество как скажем, проверка доступа, мы можем видеть что Seller может изменить только свои Adverts. Это первый вариант как можно сделать.

//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.

Другой вариант, это где клиентский слой будет вызывать changeName и changeCost напрямую у агрегата Advert. Такую реализацию я чаще вижу в разных примерах.

//Client layer call advert.changeName(name)

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

Оба ли вариант допустимы в DDD? И какой из них более правильный и логичный с точки зрения DDD?

Answer 1

[yurygolikov]

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

Answer 2

[Сергей]

имхо.
если рассматривать плюсы первого решения. оно очень простое, тривиальное, имеет мало компонентов - и следовательно содержит потенциально меньше ошибок.
минусы: оно жесткое. adverts жестко храниться в виде массива, не имеет никакой своей логики и приносит мало пользы.
возьмем немного усовершенствованное решение: есть seller, интерфейс advert и есть хранилище-интерфейс adverts. и есть реализация advertsImpl, advertImpl. Т.е. разнесли seller, хранилище и advert. мы можем менять их как желаем при условии выполнения договора - соблюдения интерфейсов.
Плюс: независимость. Логика хранилища будет в хранилище а не в seller. Гибкость в том что мы можем написать реализацию его используя массив в памяти, разного рода баз данных или хранения данных в сети.
Минус больше классов, больше текста, больше ошибок.
Далее.
Делаем отдельно seller, отдельно слой управления advert, отдельно advert.
плюс: очень гибкое решение, в слое можем реализовать любую логику работы с advert (например связанные advert, или связанные с другими сущностями ) и т.п.
минус: самое тяжелое и мутное решение.
Итого: нужно выбрать эффективное решение именно для задачи которая стоит. т.е нужно спрогнозировать как будет развиваться система.
т.е. нет абстрактного правильного решения. и тем более единственного правильного.
вероятно можно делать как можно проще, но оставляя возможность развивать систему.