агрегатов в методы других для проверки инвариантов?
вообще нет, так как ты для принятия решений достаешь стэйт другого агрегата.
Не понимаю. Не в этом ли прелесть такого моделирования, что при видно откуда у каких данных растут ноги. Если рассмотреть другой кейс: Есть водитель Есть машина Водители привязываются к машинам. У одной машины не может быть более 2 водителей, а у одного водителя более 4 машин. Мы это реализовываем так: Метод Driver.addCar: получает на входе агрегат Car 1. Проверяет, что у водителя еще есть место для новой машины. 2. Добавляет в Driver.carIds референс на машину 3. Вызывает Car.addDriver с референсом на себя 4. Если Car.addDriver фейлит, то удаляем из Driver.carIds ссылку на машину Метод Car.addDriver: получает на входе агрегат Driver 1. Проверяет есть ли место для нового водителя. Если нет, фейлит. 2. Проверяет добавлена ли машина к водителю. Если нет фейлит Потом сохраняем два агрегата. Инварианты соблюдены
Как лучше организовать принятие решений? Прокидывать только влияющие на решение значения?
Идеально - тот кто владеет данными принимает решение. Когда ты планируешь количество страниц ты по сути владение передаешь, теперь мол у тебя есть у сессии контроль На все это влияет понятие консистентности данных, насколько вероятно что пока ты данные запрашивал они могли устареть и как это влияет на консистентность. Скажем если все операции происходят последовательно и вероятность конфликтов низкая то все проще. Если же ты делаешь условный аукцион то там уже конфликты неизбежны и придется учитывать конкурентные операции
То есть решение принимается на уровне сервиса, который работает с репозиториями?
Сервис никакими данными не владеет
А кто владеет?
Давай так, а кто у нас вообще в этом цирке выступает
Выступают агрегаты, сервисы, и инфраструктура В моем манямире сервисы отвечают за взаимодействие агрегатов, запись/чтение этих самых агрегатов в бд; инфраструктура отвечает за взаимодействие с внешним миром через всякие API
А что такое агрегат? Как ты их себе представляешь.
Структура, включающая в себя кучу моделей, агрегатов, или valueObject
Что такое модели, почему агрегаты в агрегатах могут быть. К vo вопросов нет
Объект, который содержит данные, и правила их поведения
Мне всегда казалось, что агрегаты могут быть в агрегатах, не задумывался как-то над этим :/
Правила поведения - это как?)
А с термином aggregate root знаком?
Бизнес требования, иными словами Нельзя открыть страницу, которой нет в книге; нельзя иметь меньше 0 продуктов на складе
Обсуждают сегодня