yurygolikov
@yurygolikov

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

Приведу два примера. Опустим некоторые даже важные вещи из 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?
  • Вопрос задан
  • 358 просмотров
Решения вопроса 1
yurygolikov
@yurygolikov Автор вопроса
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@red-barbarian
имхо.
если рассматривать плюсы первого решения. оно очень простое, тривиальное, имеет мало компонентов - и следовательно содержит потенциально меньше ошибок.
минусы: оно жесткое. adverts жестко храниться в виде массива, не имеет никакой своей логики и приносит мало пользы.
возьмем немного усовершенствованное решение: есть seller, интерфейс advert и есть хранилище-интерфейс adverts. и есть реализация advertsImpl, advertImpl. Т.е. разнесли seller, хранилище и advert. мы можем менять их как желаем при условии выполнения договора - соблюдения интерфейсов.
Плюс: независимость. Логика хранилища будет в хранилище а не в seller. Гибкость в том что мы можем написать реализацию его используя массив в памяти, разного рода баз данных или хранения данных в сети.
Минус больше классов, больше текста, больше ошибок.
Далее.
Делаем отдельно seller, отдельно слой управления advert, отдельно advert.
плюс: очень гибкое решение, в слое можем реализовать любую логику работы с advert (например связанные advert, или связанные с другими сущностями ) и т.п.
минус: самое тяжелое и мутное решение.
Итого: нужно выбрать эффективное решение именно для задачи которая стоит. т.е нужно спрогнозировать как будет развиваться система.
т.е. нет абстрактного правильного решения. и тем более единственного правильного.
вероятно можно делать как можно проще, но оставляя возможность развивать систему.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы